‫۲ سال و ۸ ماه قبل، دوشنبه ۱۵ آذر ۱۴۰۰، ساعت ۱۴:۰۶
یک نکته: تاثیر hot reload دات نت 6 بر روی درخواست‌های HTTP سمت کلاینت

ممکن است پس از ارتقاء به دات نت 6، شاهد خطاهای BadHttpRequestException زیادی در سمت Web API شوید (البته فقط در حالت توسعه):
Microsoft.AspNetCore.Server.Kestrel.Core.BadHttpRequestException: Unexpected end of request content.
این خطا عنوان می‌کند که درخواست HTTP رسیده ناقص است و در اینجا بیشتر به معنای abort شدن آن در سمت کلاینت است. عکس العمل برنامه‌ی Blazor به یک چنین خطایی که در سمت سرور رخ داده، ریفرش کردن کل آدرس جاری و راه اندازی مجدد برنامه‌است. اما ... چرا این اتفاق رخ داده بود؟

اگر برنامه‌ی شما اطلاعاتی را در پوشه‌ی wwwroot ثبت کند، برای مثال یک بانک اطلاعاتی SQLite را در آن قرار داده‌اید، hot reload حتی این پوشه را هم تحت کنترل خود دارد و با هر تغییری در آن، حتی نوشته شدن یک رکورد در فایل بانک اطلاعاتی، مجددا برنامه را کامپایل می‌کند. همین کامپایل پشت صحنه، سبب abort شدن درخواست‌های HTTP سمت کلاینت آن و مشاهده‌ی خطاهای BadHttpRequestException سمت سرور می‌شود که عدم اطلاع از دلیل آن می‌تواند این تصور را پیش بیاورد که کدهای برنامه مشکلی دارند، اما خیر.
اگر با CLI کار می‌کنید، دستور dotnet watch run --no-hot-reload کمی وضع را بهتر می‌کند و معادل افزودن تنظیم زیر به فایل Properties\launchSettings.json است:
"profiles": {
  "Name.Server": {
      "hotReloadEnabled": false,
راه حل دیگر آن، خارج کردن پوشه‌ی wwwroot از حالت watch است که به صورت زیر در فایل csproj قابل انجام است (در سمت برنامه‌ی web api):
<ItemGroup>
  <Watch Remove="wwwroot\**\*" />
</ItemGroup>
‫۲ سال و ۸ ماه قبل، یکشنبه ۱۴ آذر ۱۴۰۰، ساعت ۱۹:۵۵
یک نکته: کاهش زمان build پروژه‌های Blazor در حالت توسعه

در پروژه‌های Blazor، خاصیت ویژه‌ی BlazorLinkOnBuild به true تنظیم شده‌است که سبب می‌شود تا موارد استفاده نشده‌ی در برنامه، از خروجی نهایی حذف شوند. این مورد هرچند حجم نهایی را کاهش می‌دهد، اما در زمان توسعه نیز فعال است و سبب بالا رفتن زمان build برنامه می‌شود؛ گاهی از اوقات تا 10 برابر! برای غیرفعال کردن آن در زمان debug و توسعه، می‌توان فایل csproj را به صورت زیر ویرایش کرد. این تنظیم در حین publish در حالت release، غیرفعال می‌شود:
<PropertyGroup>
    <BlazorLinkOnBuild  Condition="'$(Configuration)'!='Release'">false</BlazorLinkOnBuild>
</PropertyGroup>
‫۲ سال و ۹ ماه قبل، پنجشنبه ۱۱ آذر ۱۴۰۰، ساعت ۱۴:۳۸
این مثال کامل را پیگیری کنید. ذکر تمام قسمت‌های آن ضروری هست. همچنین ساختار داده هم باید یکی باشد. الان مجددا همین آزمایش را با EF-6x و آخرین نگارش وابستگی‌ها، آزمایش کردم و مشکلی نبود.
‫۲ سال و ۹ ماه قبل، سه‌شنبه ۹ آذر ۱۴۰۰، ساعت ۱۴:۱۰
یک نکته‌ی تکمیلی: دات نت 6 و hot reload آن

اگر برنامه‌های مبتنی بر دات نت 6 را به همراه فعال بودن Content Security Policy اجرا کنید، با خطای زیر در مرورگر مواجه خواهید شد:
Refused to connect to ws: because it violates the Content Security Policy directive
{
   "csp-report":{
      "document-uri":"http://localhost:5051/",
      "referrer":"",
      "violated-directive":"connect-src",
      "effective-directive":"connect-src",
      "original-policy":"default-src 'self' blob:; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline' 'unsafe-eval' ; font-src 'self'; img-src 'self' data: blob:; connect-src 'self'; media-src 'self'; object-src 'self' blob:; report-uri /api/CspReport/Log",
      "disposition":"enforce",
      "blocked-uri":"wss://localhost:52837",
      "line-number":234,
      "column-number":25,
      "source-file":"http://localhost:5051/_framework/aspnetcore-browser-refresh.js",
      "status-code":200,
      "script-sample":""
   }
}
برای رفع آن فقط کافی است تنظیم زیر را اضافه/ویرایش کنید:
connect-src 'self' wss://localhost:*
‫۲ سال و ۹ ماه قبل، شنبه ۲۹ آبان ۱۴۰۰، ساعت ۱۹:۵۸
به روز رسانی به Blazor 6x

اگر مثال فوق را بر اساس Blazor 6x اجرا کنید، با خطای زیر مواجه خواهید شد:
Microsoft.JSInterop.JSException: Failed to execute 'atob' on 'Window': The string to be decoded is not correctly encoded. 
Error: Failed to execute 'atob' on 'Window': The string to be decoded is not correctly encoded. at Object.createBlobUrl
علت اینجا است که در جهت بالا رفتن کارآیی برنامه‌های Blazor، دیگر یک byte array به صورت base64 به سمت کدهای جاوااسکریپتی ارسال نمی‌شود و مستقیما به صورت Uint8Array ارسال خواهد شد. اطلاعات بیشتر
بنابراین در کدهای فوق، قطعه کد قبلی زیر:
window.JsBinaryFilesUtils = {
  createBlobUrl: function (byteArray, contentType) {
    // The byte array in .NET is encoded to base64 string when it passes to JavaScript.
    const numArray = atob(byteArray)
      .split("")
      .map((c) => c.charCodeAt(0));
    const uint8Array = new Uint8Array(numArray);
    const blob = new Blob([uint8Array], { type: contentType });
    return URL.createObjectURL(blob);
  },
به صورت زیر ساده می‌شود و دیگر نیازی به encoding و decoding ندارد:
window.JsBinaryFilesUtils = {
  createBlobUrl: function (byteArray, contentType) {
    const blob = new Blob([byteArray], { type: contentType });
    return URL.createObjectURL(blob);
  },
‫۲ سال و ۹ ماه قبل، چهارشنبه ۲۶ آبان ۱۴۰۰، ساعت ۱۴:۲۸
اضافه شدن قابلیت کامپایل AOT به Blazor 6x

Blazor WebAssembly 6x به همراه قابلیتی است به نام ahead-of-time (AOT) compilation که در این حالت، کدهای دات نتی برنامه، مستقیما به native WebAssembly کامپایل می‌شوند. این مورد سبب بالا رفتن کارآیی برنامه خواهد شد؛ در عوض بالا رفتن حجم نهایی قابل توزیع.
اگر از AOT compilation استفاده نشود (یعنی حالت متداول)، Blazor WebAssembly در مرورگر، به کمک مفسر IL یا همان NET Intermediate Language. که به صورت WebAssembly تهیه شده‌است، اجرا خواهد شد. یک چنین حالتی به دلیل استفاده‌ی از مفسر، نسبت به حالت استفاده‌ی از JIT سمت سرور (یا همان NET just-in-time (JIT) runtime.)، اندکی کندتر است. AOT compilation جهت رفع یک چنین کمبودی ارائه شده‌است تا کدهای دات نتی را مستقیما و بدون نیاز به مفسر، تبدیل به یک native WebAssembly کند. این مورد سرعت و کارآیی برنامه‌هایی را که کارهای محاسباتی مبتنی بر CPU را انجام می‌دهند، به نحو قابل ملاحظه‌ای افزایش می‌دهد. در مقابل باید درنظر داشت که حجم نهایی WebAssembly‌های واقعی تولید شده، از نمونه‌ی IL آن‌ها بالاتر است (حدود 2 برابر) که مدت زمان ابتدایی دریافت برنامه را افزایش می‌دهند.

روش فعالسازی کامپایل AOT

ابتدا نیاز است work load آن‌را توسط دستور زیر دریافت کرد (ابزارهای کامپایل AOT، جزئی از SDK نیستند):
dotnet workload install wasm-tools
سپس برای فعالسازی آن می‌توان تنظیم زیر را به فایل csporj پروژه‌های WASM اضافه کرد:
<PropertyGroup>
  <RunAOTCompilation>true</RunAOTCompilation>
</PropertyGroup>
در این حالت با publish برنامه توسط دستور dotnet publish -c Release، مراحل تولید native WebAssemblyها طی می‌شوند و باید درنظر داشت که به علت کند بودن این پروسه، تنها در زمان publish نهایی، شاهد این عملیات خواهید بود و نه در زمان اجرای برنامه در حالت توسعه.

یک نکته: هنوز در نگارش 6.0 RTM، یکسری از قابلیت‌های AOT اضافه نشده‌اند که باید منتظر سرویس‌پک‌های آن بود. برای مثال اگر این کامپایل، بر روی پروژه‌ای که فقط سورس کد است اجرا شود، با موفقیت به پایان می‌رسد؛ اما با اضافه شدن کتابخانه‌های ثالث ممکن است با شکست مواجه شود. اگر در این حالت خطایی را دریافت کردید، عملیات publish را به صورت dotnet publish -p:RunAOTCompilation=true -bl انجام دهید. سوئیچ bl- سبب می‌شود تا فایلی به نام msbuild.binlog در ریشه‌ی پروژه‌ی شما تولید شود. این فایل در حقیقت لاگ باینری MSBuild است که توسط برنامه‌ی Viewer آن قابل مشاهده‌است. در اینجا به دنبال exit code‌ها بگردید؛ یک نمونه‌ی آن.
‫۲ سال و ۹ ماه قبل، دوشنبه ۲۴ آبان ۱۴۰۰، ساعت ۱۷:۰۰
خطری ایجاد نمیکنه 
این اطلاعات باید به صورت عمومی در هدر درخواست به مرورگر ارسال شود تا آن‌را تشخیص داده و استفاده کند. نحوه‌ی کارکرد استاندارش به همین صورت است. از هر روش دیگری هم استفاده کنید به همین صورت باید باشد.
‫۲ سال و ۹ ماه قبل، دوشنبه ۲۴ آبان ۱۴۰۰، ساعت ۱۶:۲۴
اضافه شدن ویژگی CallerArgumentExpression به C#10.0

ویژگی [CallerArgumentExpression] امکان دریافت آرگومان ارسالی به یک متد را به صورت رشته‌ای میسر می‌کند. برای مثال:
public static void LogExpression<T>(
    T value, 
    [CallerArgumentExpression("value")] string expression = null)
{
    Console.WriteLine($"{expression}: {value}");
}
با ورودی زیر:
var person = new Person("Vahid", "N.");
LogExpression(person.FirstName);
چنین خروجی را تولید می‌کند:
person.FirstName: Vahid

پارامتری که توسط ویژگی [CallerArgumentExpression] معرفی می‌شود، اختیاری بوده و به صورت خودکار توسط کامپایلر مقدار دهی می‌شود. یعنی کامپایلر فراخوانی فوق را به صورت زیر انجام می‌دهد:
LogExpression(person.FirstName, "person.FirstName");
وجود یک چنین قابلیتی، نویسندگان کتابخانه‌ها را از بکارگیری <<Expression<Func<T‌ها یا همان استاتیک ریفلکشن، رهایی می‌بخشد.

یک نمونه کاربرد دیگر آن در بررسی نال بودن مقدار پارامترهای ارسالی است که می‌توان آن‌ها را به صورت زیر خلاصه کرد:
public static void EnsureArgumentIsNotNull<T>(
   T value, 
   [CallerArgumentExpression("value")] string expression = null)
{
    if (value is null)
        throw new ArgumentNullException(expression);
}

public static void Foo(string name)
{
    EnsureArgumentIsNotNull(name); // if name is null, throws ArgumentNullException: "Value cannot be null. (Parameter 'name')"
    ...
}
پیشتر می‌بایستی با استفاده از nameof، نام پارامتر را مشخص کرد. در اینجا کامپایلر قادر است این مقدار را مشخص کند و دیگر نیازی به استفاده از روش زیر نیست:
    if (name is null)
    {
        throw new ArgumentNullException(nameof(name));
    }
البته NET 6.0. به همراه متد جدید زیر که از قابلیت فوق استفاده می‌کند، هست:
ArgumentNullException.ThrowIfNull(name);
و متد ThrowIfNull آن به صورت زیر تعریف شده‌است:
public static void ThrowIfNull(
    [NotNull] object? argument,
    [CallerArgumentExpression("argument")] string? paramName = null)

سؤال: چرا آرگومان اول این متد، هم nullable تعریف شده‌است و هم با ویژگی NotNull مزین گشته‌است؟
nullable بودن آن از این جهت است که ممکن است مقدار ارسالی به آن نال باشد. ویژگی NotNull آن به کامپایلر اعلام می‌کند که اگر این متد با موفقیت به پایان رسید، در سطرهای پس از آن، مقدار این شیء دیگر نال نیست و نیازی نیست تا به استفاده کنند اعلام کند که باید مراقب نال بودن آن باشد.