‫۶ سال و ۶ ماه قبل، شنبه ۱۲ اسفند ۱۳۹۶، ساعت ۱۶:۴۶
ارتقاء به NET Core 2.1. : حذف Microsoft.DotNet.Watcher.Tools
پس از ارتقاء به NET Core 2.1. دیگر نیازی به ذکر تنظیم زیر در فایل csproj نیست:
<ItemGroup>
   <DotNetCliToolReference Include="Microsoft.DotNet.Watcher.Tools" Version="(all versions)" />
</ItemGroup>
و تبدیل به دستورات سطوح بالا شده‌اند. یعنی بدون نیاز به نصب وابستگی خاصی، کار می‌کنند (و اگر در پروژه‌های پیشین ذکر شده‌اند، آن‌ها را حذف کنید) . اطلاعات بیشتر
‫۶ سال و ۶ ماه قبل، شنبه ۱۲ اسفند ۱۳۹۶، ساعت ۱۶:۴۵
ارتقاء به NET Core 2.1. : حذف Microsoft.DotNet.Watcher.Tools
پس از ارتقاء به NET Core 2.1. دیگر نیازی به ذکر تنظیم زیر در فایل csproj نیست:
<ItemGroup>
   <DotNetCliToolReference Include="Microsoft.DotNet.Watcher.Tools" Version="(all versions)" />
</ItemGroup>
و تبدیل به دستورات سطوح بالاتر شده‌اند. یعنی بدون نیاز به نصب وابستگی خاصی، کار می‌کنند (و اگر در پروژه‌های پیشین ذکر شده‌اند، آن‌ها را حذف کنید) . اطلاعات بیشتر
‫۶ سال و ۶ ماه قبل، شنبه ۱۲ اسفند ۱۳۹۶، ساعت ۱۳:۱۸
ارتقاء به ASP.NET Core 2.1 - معرفی درجه‌ی سازگاری فریم ورک

پس از نصب یک SDK جدید، بهترین روش یافتن تغییرات انجام شده، ایجاد یک پوشه‌ی خالی جدید، باز کردن خط فرمان در این پوشه و سپس صدور دستور dotnet new mvc است. به این ترتیب بدون داشتن هیچ نوع IDE خاصی می‌توانید یک پروژه‌ی جدید مبتنی بر آن SDK را ایجاد کنید.
در قالب پیش‌فرض نگارش 2.1، سطر فعالسازی Mvc به صورت زیر تغییر کرده‌است:
public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_1);
}
در اینجا CompatibilityVersion یک چنین تعریفی را دارد:
public enum CompatibilityVersion
{
   Version_2_0 = 0,
   Version_2_1 = 1,
   Latest = int.MaxValue
}
برای مثال تنظیم آن به Version_2_0‌، صرفنظر از نگارش جاری Mvc مورد استفاده، رفتار نگارش 2.0 را برای برنامه تنظیم می‌کند که البته هدف اصلی آن‌ها در حقیقت چنین چیزی است:
services.AddMvc()
   .SetCompatibilityVersion(CompatibilityVersion.Version_2_1) // Give me all of the 2.1 behaviors
   .AddMvcOptions(options =>
   {
      options.AllowCombiningAuthorizeFilters = false; // don't combine authorize filters (keep 2.0 behavior)
      options.AllowEmptyInputInBodyModelBinding = false; // shouldn't treat empty input as valid.
   });
و فلسفه‌ی آن نیز به این صورت است: چگونه یک فریم‌ورک را بهبود ببخشیم، بدون اینکه ارتقاء به نگارش‌های جدید را سخت‌تر کنیم؟
برای مثال در نگارش 2.1، اگر بدنه‌ی درخواست رسیده خالی باشد، خطایی را به ModelState اضافه می‌کند که پیشتر اینگونه نبوده‌است و یا ترکیب سیاست‌های امنیتی پیش از نگارش 2.1، آنطور که تصور میشده، کار نمی‌کرده‌است و این باگ اکنون اصلاح شده‌است. اگر پس از به روز رسانی به نگارش 2.1، این دو تغییر، برنامه‌ی شما را به هم می‌ریزند، یا می‌توانید CompatibilityVersion را به Version_2_0 تعیین کنید (لغو کلی تغییرات رفتاری نگارش 2.1) و یا Version_2_1 را انتخاب کنید و توسط متد AddMvcOptions، گزینه‌های مختلف این تغییرات انجام شده را به دلخواه انتخاب کنید.

نکته‌ی مهم: این رفتارها تا ابد نگهداری نخواهند شد. یعنی با ارائه‌ی نگارش 3.0 و انتخاب آن، دیگر دسترسی به رفتارهای قدیمی قابل انتخاب برای نگارش 2.1 نخواهید داشت. به همین جهت در این بین، فرصت بررسی، انطباق و به روز رسانی برنامه‌ی خود را خواهید داشت.
‫۶ سال و ۶ ماه قبل، جمعه ۱۱ اسفند ۱۳۹۶، ساعت ۱۲:۴۰
ارتقاء به ASP.NET Core 2.1: امکان کامپایل فایل‌های Razor در پروژه‌های Class library (یا پشتیبانی از طراحی افزونه‌پذیر به صورت توکار)


در نگارش 2.1 می‌توان فایل‌های razor (هم صفحات Razor و هم Viewهای Razor) را به همراه کنترلرها و مدل‌های آن‌ها داخل class libraries مجزا قرار داد و استفاده کرد. استفاده کننده فقط کافی است ارجاعی را به این کتابخانه‌ها اضافه کند تا امکانات آن‌ها قابل استفاده شوند.
فعالسازی این قابلیت در یک class library نیاز به تغییرات ذیل را در یک فایل csproj دارد (مشخص کردن sdk، تعیین کامپایل شدن viewها و صفحاتی که باید الحاق شوند):
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <ResolvedRazorCompileToolset>RazorSdk</ResolvedRazorCompileToolset>
    <RazorCompileOnBuild>true</RazorCompileOnBuild>
    <IncludeContentInPack>false</IncludeContentInPack>
  </PropertyGroup>
<ItemGroup>
    <Content Include="Pages\**\*.cshtml" />
  </ItemGroup>
<ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.Mvc" Version="2.1.0-preview1-final" />
  </ItemGroup>
</Project>

یک نکته‌ی تکمیلی
اگر برنامه‌های هاست کننده‌ی این پلاگین‌ها، دقیقا در مسیرهای متناظری صفحات و یا Viewهای Razor را قرار دهد، می‌تواند این صفحات را بازنویسی کند.
‫۶ سال و ۶ ماه قبل، پنجشنبه ۱۰ اسفند ۱۳۹۶، ساعت ۱۷:۴۸
ارتقاء به ASP.NET Core 2.1: بهبود اعتبارسنجی پارامترها

تا پیش از نگارش 2.1، برای اعمال اعتبارسنجی به اطلاعات دریافتی از کاربر باید به صورت زیر عمل کرد:
public class UserModel   
{
   [Required, EmailAddress]
   public string Email { get; set; }
 
   [Required, StringLength(1000)]
   public string Name { get; set; }
}
اطلاعات مدنظر به صورت یک کلاس مدل تعریف شده و سپس ویژگی‌های اعتبارسنجی به خواص این کلاس اضافه می‌شوند.
در این حالت در اکشن متد تعریفی با بررسی ModelState.IsValid می‌توان وضعیت اعتبارسنجی اطلاعات دریافتی از سمت کاربر را مشاهده کرد:
public IActionResult SaveUser(UserModel model)
{
     if(!ModelState.IsValid)
     {

 در نگارش 2.1 الزامی به تعریف این کلاس مدل نیست و ویژگی‌های اعتبارسنجی را به پارامترهای تعریف اکشن متد هم می‌توان اعمال کرد:
public IActionResult SaveUser(
     [Required, EmailAddress] string Email  
     [Required, StringLength(1000)] string Name)
{
    if(!ModelState.IsValid)

یک نکته‌ی تکمیلی: اعمال ویژگی Required به non-nullable value types تاثیری ندارد. به همین جهت ویژگی دیگری به نام BindRequired نیز در اینجا اضافه شده‌است تا برای نمونه در مثال زیر اطمینان حاصل شود که testId از مقادیر route و qty از مقادیر کوئری استرینگ مقدار دهی شده‌اند:
public IActionResult Get([BindRequired, FromRoute] Guid testId, [BindRequired, FromQuery] int qty)   
{
   if(!ModelState.IsValid)

- به این ترتیب می‌توان تعداد ViewModelهای مورد نیاز یک برنامه را به شدت کاهش داد. البته نکته‌ی «بررسی Bad code smell ها: تعداد زیاد پارامترهای ورودی» و «آشنایی با Refactoring - قسمت 7» را هم مدنظر داشته باشید و زیاده‌روی نکنید!
- همچنین اگر ویژگی [ApiController] را نیز به کنترلر جاری اعمال کنید، بررسی ModelState.IsValid نیز به صورت خودکار انجام خواهد شد و نیازی به کدنویسی اضافه‌تری نخواهد داشت.
‫۶ سال و ۶ ماه قبل، سه‌شنبه ۸ اسفند ۱۳۹۶، ساعت ۲۳:۳۰
یک نکته‌ی تکمیلی
نمونه‌ی بهبود یافته‌ی کلاس AppErrorHandler را در اینجا می‌توانید مشاهده کنید. این نمونه به وابستگی‌های ذیل نیاز دارد:
npm install stacktrace-js --save
npm install @types/stacktrace-js --save-dev
یک نکته‌ی تکمیلی
اگر نکات مطلب «استفاده از مسیرهای مطلق در حین import ماژول‌ها در برنامه‌های مبتنی بر TypeScript» را به پروژه‌ی جاری اعمال کنیم، به این تغییرات خواهیم رسید.