وحید نصیری وحید نصیری
تغییرات مهم مقایسه‌‌ی رشته‌ها در NET 5.0.
‫۱ سال و ۳ ماه قبل، شنبه ۱۶ اردیبهشت ۱۴۰۲، ساعت ۱۷:۳۳
یک نکته‌ی تکمیلی: روش بررسی خودکار این موارد

فقط کافی است ابتدا آنالایزرهای توکار SDK جاری را فعال کنید:
<Project Sdk="Microsoft.NET.Sdk">
    <PropertyGroup>
        <EnableNETAnalyzers>true</EnableNETAnalyzers>
    </PropertyGroup>
</Project>
سپس یک فایل editorconfig. خالی را در کنار فایل sln. ایجاد کرده و به صورت زیر تکمیل کنید: 
[*.cs]

# CA1304: Specify CultureInfo
# Help link: https://learn.microsoft.com/dotnet/fundamentals/code-analysis/quality-rules/ca1304
dotnet_diagnostic.CA1304.severity = error

# CA1305: Specify IFormatProvider
# Help link: https://learn.microsoft.com/dotnet/fundamentals/code-analysis/quality-rules/ca1305
dotnet_diagnostic.CA1305.severity = error

# CA1307: Specify StringComparison for clarity
# Help link: https://learn.microsoft.com/dotnet/fundamentals/code-analysis/quality-rules/ca1307
dotnet_diagnostic.CA1307.severity = error

# CA1308: Normalize strings to uppercase
# Help link: https://learn.microsoft.com/dotnet/fundamentals/code-analysis/quality-rules/ca1308
dotnet_diagnostic.CA1308.severity = error

# CA1309: Use ordinal string comparison
# Help link: https://learn.microsoft.com/dotnet/fundamentals/code-analysis/quality-rules/ca1309
dotnet_diagnostic.CA1309.severity = error

# CA1310: Specify StringComparison for correctness
# Help link: https://learn.microsoft.com/dotnet/fundamentals/code-analysis/quality-rules/ca1310
dotnet_diagnostic.CA1310.severity = error

# CA1311: Specify a culture or use an invariant version
# Help link: https://learn.microsoft.com/dotnet/fundamentals/code-analysis/quality-rules/ca1311
dotnet_diagnostic.CA1311.severity = error

# CA1820: Test for empty strings using string length
# Help link: https://learn.microsoft.com/dotnet/fundamentals/code-analysis/quality-rules/ca1820
dotnet_diagnostic.CA1820.severity = error

# CA1834: Consider using 'StringBuilder.Append(char)' when applicable
# Help link: https://learn.microsoft.com/dotnet/fundamentals/code-analysis/quality-rules/ca1834
dotnet_diagnostic.CA1834.severity = error

# CA1858: Use 'StartsWith' instead of 'IndexOf'
# Help link: https://learn.microsoft.com/dotnet/fundamentals/code-analysis/quality-rules/ca1858
dotnet_diagnostic.CA1858.severity = error

# CA2249: Consider using 'string.Contains' instead of 'string.IndexOf'
# Help link: https://learn.microsoft.com/dotnet/fundamentals/code-analysis/quality-rules/ca2249
dotnet_diagnostic.CA2249.severity = error

# CA2251: Use 'string.Equals'
# Help link: https://learn.microsoft.com/dotnet/fundamentals/code-analysis/quality-rules/ca2251
dotnet_diagnostic.CA2251.severity = error
یک نکته‌ی تکمیلی: روشی برای عدم استفاده از Razor Pages جهت لاگین کاربران در برنامه‌های Blazor Server

در این سری، از razor pages به همراه قالب پیش‌فرض ASP.NET Core Identity، جهت پیاده سازی ورود کاربران به سیستم، استفاده شده‌است. یعنی کاربر یکبار از فضای Blazor Server خارج شده و وارد یک برنامه‌ی ASP.NET Core Razor Pages معمولی می‌شود؛ لاگین می‌کند (در یک ناحیه‌ی مخصوص razor pages) و سپس مجددا وارد قسمت Blazor Server می‌شود که ... تجربه‌ی کاربری مطلوبی را به همراه ندارد. علت این خروج و ورود را هم در این مطلب می‌توانید مطالعه کنید: «دستیابی به HttpContext در Blazor Server». هدف این بوده که بتوان با استفاده از HttpContext مهیای در razor pages (و نه توسط اتصال web socket یک برنامه‌ی blazor server)، کوکی‌های پس از لاگین موفق را به سمت مرورگر ارسال و ثبت کرد و درگیر مشکلات به همراه دسترسی به HttpContext در برنامه‌های Blazor server نشد.
راه دیگری هم برای مواجه شدن با این مشکل وجود دارد: حذف قسمت razor pages؛ حذف نیاز به خروج و ورود از برنامه‌ی blazor server و ... استفاده از ProtectedBrowserStorage که اکنون جزئی از blazor server استاندارد است؛ جهت ثبت اطلاعات user claims و عدم استفاده از کوکی‌ها که نیاز به دسترسی به HttpContext را دارند. اگر علاقمند به مشاهده‌ی یک مثال کامل در این زمینه هستید، می‌توانید به پروژه‌ی « BlazorServerAuthenticationAndAuthorization   » مراجعه کنید. در اینجا یک CustomAuthenticationStateProvider را به کمک ProtectedSessionStorage طراحی و استفاده کرده تا نیاز به کار با کوکی‌ها برطرف شود و دیگر نیازی به استفاده از razor pages نباشد. البته باید دقت داشت که SessionStorage محدود به tab جاری است و اگر نیاز است اطلاعات آن در تمام برگه‌های باز شده در دسترس باشد، بهتر است از ProtectedLocalStorage استفاده کرد. همچنین باید دقت داشت که چون این protected storageها برای رمزنگاری خودکار اطلاعات از ASP.NET Core data protection API استفاده می‌کنند، نکات مطلب « غیرمعتبر شدن کوکی‌های برنامه‌های ASP.NET Core هاست شده‌ی در IIS پس از ری‌استارت آن » نیز در مورد آن‌ها صادق است.
وحید نصیری وحید نصیری
چه زمان‌هایی یک برنامه‌ی ASP.NET ری استارت می‌شود؟
‫۱ سال و ۳ ماه قبل، پنجشنبه ۱۴ اردیبهشت ۱۴۰۲، ساعت ۱۳:۳۷
یک نکته‌ی تکمیلی: چگونه یک برنامه‌ی هاست شده‌ی در IIS را همواره زنده (در حال اجرا) نگه داریم؟

application pool برنامه‌های هاست شده‌ی در IIS، پس از مدتی بیکاری، خاموش می‌شوند. راه اندازی مجدد آن‌ها هم وابسته به رسیدن یک درخواست جدید به آن‌ها است. یعنی اگر برای مثال بخواهید یک کار پس زمینه‌ای را توسط یک برنامه‌ی ASP.NET مدیریت کنید، احتمال از کار افتادن آن به علت خاموش شدن و عدم راه اندازی خودکار application pool، بسیار زیاد است. برای رفع این مشکل و زنده نگه‌داشتن برنامه اگر از یک سیستم توسعه‌ی معمولی استفاده می‌کنید، ابتدا مطمئن شوید که Application Initialization Module که جزئی از Windows Features است، نصب شده‌است:

و اگر از ویندوز سرور استفاده می‌کنید، باید Application Initialization را در قسمت Application Development فعال کنید: 

- Open the Add Roles and Features Wizard.
- In the Select role services panel, open the Application Development node.
- Select the checkbox for Application Initialization.

سپس به تنظیمات application pool برنامه مراجعه کرده و دو تغییر زیر را اعمال کنید:
Start Mode -> AlwaysRunning
Idle Time-Out (minutes) -> 0


همچنین حالت Preload برنامه را نیز باید فعال کرد و برنامه هم باید در حالت In-Process hosting model اجرا شود:
 
Connections panel -> Sites node -> Right-click the app ->
Manage Website > Advanced Settings -> Set Preload Enabled -> True

وحید نصیری وحید نصیری
تولید خودکار کدهای سمت کلاینت بر اساس OpenAPI Specification
‫۱ سال و ۳ ماه قبل، پنجشنبه ۱۴ اردیبهشت ۱۴۰۲، ساعت ۱۳:۰۶
یک نکته‌ی تکمیلی: ابزار CLI مایکروسافت برای تولید خودکار کدهای کلاینت #C براساس استاندارد OpenAPI

ابزار جدید Microsoft.dotnet-openapi  کار تولید کدهای یک کلاینت سی‌شارپی را بر اساس OpenAPI Specification انجام می‌دهد. برای استفاده‌ی از آن، ابتدا با استفاده از دستور dotnet tool install -g Microsoft.dotnet-openapi، کار نصب ابزار CLI آن انجام خواهد شد و سپس برای استفاده از آن، به فایل csproj. خود، تنظیمات زیر را اضافه کنید: 
<Project Sdk="Microsoft.NET.Sdk.Worker">
  <ItemGroup>
    <OpenApiReference Include="OpenAPIs\v1.json" CodeGenerator="NSwagCSharp" 
         Namespace="GettingStarted" ClassName="MyClient">
      <SourceUri>https://geo.api.vlaanderen.be/capakey/v2/swagger/docs/v1</SourceUri>
    </OpenApiReference>
  </ItemGroup>
</Project>
تنظیم Include آن، یکی کپی محلی از فایل json ذکر شده‌ی در SourceUri را تهیه می‌کند. سایر موارد، تنظیمات فضای نام و کلاس تولید شده‌ی مرتبط است.
حتی بر اساس این ابزار CLI، خود ویژوال استودیو هم گزینه‌ی جدید Add –> Service Reference -> OpenAPI  را اضافه کرده‌است که تنظیمات یاد شده‌ی فوق را توسط یک رابط کاربری جدید دریافت می‌کند:

وحید نصیری وحید نصیری
غنی سازی کامپایلر C# 9.0 با افزونه‌ها
‫۱ سال و ۳ ماه قبل، دوشنبه ۱۱ اردیبهشت ۱۴۰۲، ساعت ۱۸:۴۷
یک نکته‌ی تکمیلی: تنظیم severity = suggestion در فایل editorconfig. اعمال نمی‌شود!
- اگر تنظیمات آنالیزری را در حالت «توصیه» تنظیم کردید، اما باز هم در حین Build مشاهده کردید که اعمال نمی‌شود و تنظیم دیگری برای آن اعمال شده، ممکن است به علت وجود پروسه‌های dotnet.exe در حال اجرای پیشین باشد. تمام آن‌ها را از طریق task manager خاتمه دهید و مجددا سعی کنید.
- و یا اگر از فایل Directory.Build.props استفاده می‌کنید، ممکن است در قسمت‌های NoError و NoWarn، یکسری از تنظیمات را بازنویسی کرده باشید (مانند مثال مطرح شده‌ی در مطلب جاری).