نظرات مطالب
آزمون‌های یکپارچگی در برنامه‌های ASP.NET Core
یک نکته‌ی تکمیلی: دسترسی به کلاس Program از نوع internal دات نت 6 در یک پروژه‌ی دیگر

در مطلب فوق چنین قطعه کدی را داریم:
public class CustomWebApplicationFactory : WebApplicationFactory<Program>
اگر از top level programs دات نت 6 استفاده کنیم، اینبار کلاس Program دیگر public نیست و internal است. به همین جهت نمی‌توان از کلاس Program در یک اسمبلی دیگر استفاده کرد؛ مگر اینکه در فایل csproj پروژه‌ی اصلی، تنظیم زیر را اضافه کنیم. در اینجا Include به نام پروژه‌ی Test (و فضای نام اصلی اسمبلی آن) اشاره می‌کند. همچنین چون Program از نوع internal است، اینبار کلاس فکتوری تهیه شده نیز باید internal تعریف شود:
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <InternalsVisibleTo Include="ProjName.Tests" />
  </ItemGroup>
</Project>
اشتراک‌ها
پشتیبانی از ES6 Modules در مرورگر Edge

To light up ES6 modules and other experimental JavaScript features in Edge, you can navigate to  about:flags  and select the “Enable experimental JavaScript features” flag.
Read more at https://blogs.windows.com/msedgedev/2016/05/17/es6-modules-and-beyond/#kifM95C2F1kLGvJI.99  

پشتیبانی از ES6 Modules در مرورگر Edge
مطالب
روش ایجاد پروژه‌ها‌ی کتابخانه‌ای کامپوننت‌های Blazor
جهت به اشتراک گذاشتن کامپوننت‌های سفارشی Blazor در پروژه‌های مختلف، امکان بسته بندی آن‌ها به صورت کتابخانه‌های کامپوننت‌ها نیز پیش‌بینی شده‌است که می‌توانند به همراه فایل‌های CSS ،JS و تصاویر هم باشند.


روش ایجاد یک پروژه‌ی کتابخانه‌ای، از کامپوننت‌های Blazor

اگر از ویژوال استودیو استفاده می‌کنید، نوع «Razor Class Library»، پروژه‌های مخصوص کتابخانه‌های کامپوننت‌های Blazor را آغاز می‌کند و اگر می‌خواهید از CLI استفاده کنید، باید از دستور «dotnet new razorclasslib» استفاده کرد؛ که قابلیت تبدیل به بسته‌های نیوگت را با دستور dotnet pack داشته و به این ترتیب می‌توان آن‌ها را به اشتراک گذاشت و یا حتی می‌توان ارجاعی از این پروژه را در سایر پروژه‌های شخصی، مورد استفاده قرار داد.
ساختار پیش‌فرض فایل csproj اینگونه پروژه‌ها به صورت زیر است:
<Project Sdk="Microsoft.NET.Sdk.Razor">
  <PropertyGroup>
    <TargetFramework>net5.0</TargetFramework>
  </PropertyGroup>
  
  <ItemGroup>
    <SupportedPlatform Include="browser" />
  </ItemGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.Components.Web" Version="5.0.6" />
  </ItemGroup>
</Project>

روش افزودن فایل‌های ثابت مورد استفاده‌ی در کتابخانه

پروژه‌ی پیش‌فرضی که در اینجا ایجاد می‌شود، به همراه یک پوشه‌ی wwwroot نیز هست. این پوشه محلی است که باید فایل‌های ثابت اشتراکی پروژه را مانند فایل‌های CSS و JS مورد استفاده، قرار داد.
این نوع پروژه‌ها از ویژگی Isolated CSS و یا Isolated JS ارائه شد‌ه‌ی در Blazor 5x نیز پشتیبانی می‌کنند.


روش استفاده‌ی از فایل‌های ثابت موجود در یک کتابخانه

این فایل‌های ثابت به همراه بسته‌ی نهایی پروژه، به صورت خودکار توزیع می‌شوند (و نیازی به ارائه‌ی مجزای آن‌ها نیست) و برای استفاده‌ی از آن‌ها در پروژه‌های دیگر، باید از روش مسیردهی زیر استفاده کرد:
/_content/PackageId/MyImage.png
- content_ مسیر آغاز کننده‌ی دسترسی به منابع یک کتابخانه‌ی کامپوننت‌های Blazor است.
- PackageId عموما همان نام پروژه‌ی مورد استفاده‌است (نام فایل csproj مانند MyBlazorComponentLibrary). هرچند می‌توان آن‌را به صورت مجزایی در فایل csproj نیز مقدار دهی کرد.
- در این مثال MyImage.png، نام منبعی است که قرار است از آن استفاده کنیم و پیشتر در پوشه‌ی wwwroot کتابخانه، کپی شده‌است و یا حتی می‌توان زیر پوشه‌هایی را نیز در اینجا ایجاد و از آن‌ها استفاده کرد؛ مانند:
/_content/MyBlazorComponentLibrary/scripts/HelloWorld.js
همچنین باید دقت داشت که مداخل فایل‌های اسکریپتی کتابخانه را مانند:
<script src="_content/MyBlazorComponentLibrary/exampleJsInterop.js"></script>
در برنامه‌های Blazor WASM باید به فایل wwwroot/index.html و در برنامه‌های Blazor Server به فایل Pages/_Host.cshtml افزود و این مداخل باید پیش از یکی از فایل‌های framework/blazor.server.js_ و یا framework/blazor.webassembly.js_ تعریف شوند.


روش استفاده‌ی از کتابخانه‌ی نهایی تولید شده

برای استفاده‌ی از کتابخانه‌ی نهایی تولید شده یا می‌توان ارجاعی را به فایل csproj آن، به پروژه‌ی خود افزود:
<ItemGroup>
   <ProjectReference Include="..\MyBlazorComponentLibrary\MyBlazorComponentLibrary.csproj" />
</ItemGroup>
و یا می‌توان بسته‌ی نیوگت آن‌را (در صورت وجود) نصب کرد.

پس از آن، جهت سهولت استفاده‌ی از این کامپوننت‌های اشتراکی، بهتر است فضای نام آن‌ها را به فایل Imports.razor_ پروژه‌ی خود افزود؛ تا نیازی به تعریف آن‌ها در تمام کامپوننت‌های مورد استفاده نباشد.
نظرات مطالب
ارتقاء به ASP.NET Core 2.0 - معرفی بسته‌ی Microsoft.AspNetCore.All
در NET Core 3x. دیگر بسته‌های نیوگت Shared framework به صورت جداگانه تولید و توزیع نمی‌شوند

فرض کنید کتابخانه‌ای را مخصوص ASP.NET Core 2x تولید کرده‌اید و این کتابخانه، وابستگی را به بسته‌ی Microsoft.AspNetCore.Mvc.Core دارد و اکنون قصد دارید نگارش 3x آن‌را تهیه کنید.  اگر به نیوگت مراجعه کنید، آخرین نگارشی که از آن موجود است، 2.2.5 است و دیگر هیچ خبری، حتی از نگارش‌های preview مربوط به 3x، در اینجا وجود ندارد. علت اینجا است که تیم ASP.NET Core تصمیم گرفته‌است، دیگر بسته‌های نیوگت زیر مجموعه‌ی Microsoft.AspNetCore.App را به صورت جداگانه تولید و منتشر نکند (و دیگر آخرین نگارش‌های آن‌ها را در سایت نیوگت نخواهید یافت).
همچنین نحوه‌ی تعریف متاپکیج Microsoft.AspNetCore.App اینبار از طریق PackageReferenceها صورت نمی‌گیرد و بر اساس معرفی FrameworkReferenceها انجام شده‌است:
<ItemGroup>
   <FrameworkReference Include="Microsoft.AspNetCore.App" />
</ItemGroup>
 به همین جهت فایل csproj نگارش 3x، دیگر شامل Microsoft.AspNetCore.App نیست (حتی تعریف FrameworkReference فوق را نیز به همراه ندارد). علت اینجا است که اگر TargetFramework پروژه‌ی وب، به netcoreapp3.0 اشاره کند، به صورت خودکار می‌توانید از آخرین نگارش Microsoft.AspNetCore.App نصب شده‌ی توسط SDK، در برنامه‌ی خود استفاده کنید و نیاز به هیچ نوع تنظیم اضافه‌تری ندارد و ذکر netcoreapp3.0، به معنای استفاده‌ی خودکار از تمام بسته‌های نیوگت به همراه Shared framework همراه با SDK جاری است. بدیهی است هر وابستگی دیگری که در لیست Microsoft.AspNetCore.App قرار نداشته باشد، باید همانند سابق نصب شود.

یک نکته: تمام بسته‌های جدید تولید شده، بر اساس netcoreapp3.0 تهیه شده‌اند؛ منهای بسته‌های Microsoft.Extensions و همچنین Entity Framework Core که هنوز بر پایه‌ی NET Standard. تهیه می‌شوند. بنابراین فایل پروژه‌ی یک class library که بخواهد از بسته‌های مبتنی بر netcoreapp3.0 استفاده کند و همچنین بسته‌های Microsoft.AspNetCore.App را نیز لحاظ کند، چنین شکلی را پیدا می‌کند (و TargetFramework آن دیگر برای مثال netstandard2.0 نمی‌تواند باشد):
<Project Sdk="Microsoft.NET.Sdk">
   <PropertyGroup>
      <TargetFramework>netcoreapp3.0</TargetFramework>
   </PropertyGroup>
   <ItemGroup>
      <FrameworkReference Include="Microsoft.AspNetCore.App" />
   </ItemGroup>
</Project>
نظرات مطالب
ارتقاء به ASP.NET Core 2.0 - معرفی بسته‌ی Microsoft.AspNetCore.All
ارتقاء به ASP.NET Core 3.0 و سرنوشت metapackageهای Microsoft.AspNetCore

پس از نصب SDK جدید، اگر دستور dotnet new mvc را صادر کنید، فایل csproj تولید شده‌ی آن تنها دارای TargetFramework ای معادل netcoreapp3.0 است و نه هیچ مورد دیگری:
<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>netcoreapp3.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
  </ItemGroup>
</Project>
بنابراین برای ارتقاء پروژه‌های قبلی به نگارش 3 آن:
- ابتدا TargetFramework را به netcoreapp3.0 تنظیم کنید.
- سپس تمام PackageReferenceهایی را که به بسته‌های Microsoft.AspNetCore.All و یا Microsoft.AspNetCore.App اشاره می‌کنند، حذف کنید.
- ارجاع به بسته‌ی Microsoft.AspNetCore.Razor.Design را نیز حذف کنید.
- اگر پیشتر خاصیت AspNetCoreHostingModel را به حالت درون پروسه‌ای تنظیم کرده‌اید، آن‌را حذف کنید؛ چون حالت پیش‌فرض نگارش 3 است.
- حذف شدن JSON.NET را مدنظر داشته باشید.
- تغییرات حالت ثبت سرویس‌های MVC و Razor Pages و Web API را مدنظر داشته باشید.
- مسیریابی آن نیز Endpoint routing شده‌است.
- نقطه‌ی آغازین آن نیز بازنویسی شده‌است.
نظرات مطالب
بررسی بهبودهای پروسه‌ی Build در دات‌نت 8

یک نکته‌ی تکمیلی: تعدیل خطاهای بررسی امنیتی بسته‌های نیوگت در حالت کار offline در دات‌نت 8

اگر در پروژه‌ی خود، تنظیم گزارش اخطارها را به صورت خطا، فعال کرده باشید:

<PropertyGroup>
   <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
</PropertyGroup>

و ... از دات‌نت 8 هم استفاده می‌کنید، هربار با صدور فرمان dotnet build و یا dotnet restore، با خطای زیر مواجه خواهید شد:

warning NU1900: Error occurred while getting package vulnerability data: (more information)

البته یکبار که اطلاعات امنیتی بسته‌ها ذخیره شدند، ممکن است در طول یک روز دیگر شاهد این خطا نباشید، اما ... دوباره فردا تکرار خواهد شد و اگر بخواهید offline کار کنید، این خطا واقعا مشکل ساز می‌شود!

برای کنترل آن یا می‌توان به صورت زیر عمل کرد:

<PropertyGroup>
    <NuGetAudit>false</NuGetAudit>
</PropertyGroup>

که بررسی امنیتی بسته‌های نیوگت را کاملا غیرفعال می‌کند و یا می‌توان به صورت زیر، این بررسی را فقط به حالت Release خلاصه کرد:

<PropertyGroup>
  <NuGetAudit>true</NuGetAudit>
  <NuGetAuditMode>all</NuGetAuditMode>
  <NuGetAuditLevel>low</NuGetAuditLevel>
  <WarningsNotAsErrors Condition="'$(Configuration)' != 'Release'">
    $(WarningsNotAsErrors);NU1900;NU1901;NU1902;NU1903;NU1904
  </WarningsNotAsErrors>
</PropertyGroup>

در این حالت هرچند اخطارهای NU1900 و دردسترس نبودن اینترنت ظاهر می‌شوند، اما دیگر به‌عنوان خطا پردازش نخواهند شد (چون در قسمت WarningsNotAsErrors ذکر شده‌اند) و پروسه‌ی build را متوقف نمی‌کنند.

نظرات مطالب
کاهش تعداد بار تعریف using ها در C# 10.0 و NET 6.0.
یک نکته‌ی تکمیلی: ترفندی برای معرفی Stubs توسط ویژگی global using statements در unit tests

برای نمونه متد زیر را درنظر بگیرید:
public static string CurrentInvariantMonthName()
    {
        var month = DateTimeOffset.UtcNow.Month;
        return CultureInfo
            .InvariantCulture
            .DateTimeFormat
            .GetMonthName(month);
    }
در کل نوشتن آزمون واحد برای متدهایی که با زمان و خواصی مانند UtcNow و یا Now، کار می‌کنند، مشکل است. در آزمون‌های واحد نیاز داریم تا یک خروجی مشخص را با مقداری از پیش معلوم، مقایسه کنیم تا اطمینان حاصل شود که عملیات صورت گرفته، صحیح است. اما UtcNow هر بار متغیر است.
برای حل این مشکل، با استفاده از ویژگی global using statements و compiler directives، می‌توان دو مفهوم متفاوت را برای زمان ارائه داد:
#if MOCK_TIME
global using DateTimeOffset = StubDateTimeOffset; 
#else
global using DateTimeOffset = System.DateTimeOffset;
#endif

public static class StubDateTimeOffset
{
    private static System.DateTimeOffset? value;
    
    public static System.DateTimeOffset UtcNow 
        => value ?? System.DateTimeOffset.UtcNow ;
    
    public static void Set(System.DateTimeOffset dateTimeOffset) {
        value = dateTimeOffset;
    }

    public static void Reset() => value = null;
}
در اینجا یک فایل خالی cs. ایجاد شده و قطعه کد فوق در آن درج می‌شود. در این حالت اگر توسط تنظیمات کامپایلر در فایل csproj برنامه، MOCK_TIME فعال شود، مفهوم DateTimeOffset، دیگر همان System.DateTimeOffset استاندارد نخواهد بود؛ بلکه از یک کلاس بدلی به نام StubDateTimeOffset تامین می‌شود. برای فعالسازی MOCK_TIME هم می‌توان به صورت زیر عمل کرد که این تعریف، در فایل csproj پروژه‌ی آزمایشی قرار می‌گیرد:
<PropertyGroup Condition=" '$(Configuration)' == 'Debug' ">
   <DefineConstants>MOCK_TIME</DefineConstants>
</PropertyGroup>
پس از این تغییر، اینبار کلاس StubDateTimeOffset، تامین کننده‌ی DateTimeOffset در آزمون‌های واحد خواهد بود و در این آزمون‌ها می‌توان با مقدار دهی DateTimeOffset به صورت زیر، هربار آزمایشات را بر اساس یک UtcNow «مشخص» انجام داد:
// set time
StubDateTimeOffset.Set(new(new(2022, 7, 1)));