‫۵ سال و ۱ ماه قبل، چهارشنبه ۱۶ مرداد ۱۳۹۸، ساعت ۲۳:۳۵
- قسمت web api برنامه با mvc یکپارچه هست؟ اگر بله، برای کار با web api نیازی به این روش ندارید. همینقدر که کاربر برای مثال از طریق روش‌هایی مانند ASP.NET Identity و یا Forms authentication به سایت وارد شده باشد، کوکی حاصل از اعتبارسنجی آن‌ها، به همراه اعمال Ajax ای مختص Web API هم به صورت خودکار ارسال می‌شود و ... کاربر با موفقیت اعتبارسنجی خواهد شد. پروژه‌ی مطلب «اعمال تزریق وابستگی‌ها به مثال رسمی ASP.NET Identity» یک قسمت Web API محافظت شده هم دارد؛ با این view که کاملا عادی به نظر می‌رسد. چون سیستم یکپارچه هست.
- کاربرد JWT بیشتر در برنامه‌های SPA مانند Angular است: «احراز هویت و اعتبارسنجی کاربران در برنامه‌های Angular»
در اینجا کاربر پس از لاگین (از طریق صفحه‌ی لاگینی، کاملا عادی و معمولی که هیچ اطلاعاتی هم از پیش در آن ذخیره نشده)، چیزی را که سمت کلاینت ذخیره می‌کند (برای مثال در local storage مرورگر)، فقط توکن‌های دریافتی پس از اعتبارسنجی موفق است و نه کلمه‌ی عبور و نه هیچ اطلاعات دیگری. سپس در هر درخواست به منابع محافظت شده‌ی سمت سرور، صرفا این توکن‌ها را ارسال می‌کند تا توسط آن، کار اعتبارسنجی خودکار کاربر صورت گیرد و هویت و همچنین سطوح دسترسی آن مشخص شوند.
- مثالی که در این پروژه ارائه شده، نمونه‌ی دیگر «آزمایش Web APIs توسط Postman - قسمت ششم - اعتبارسنجی مبتنی بر JWT» است؛ جهت ارائه‌ی یک سری مفهوم.
‫۵ سال و ۱ ماه قبل، چهارشنبه ۱۶ مرداد ۱۳۹۸، ساعت ۱۸:۳۶
پس از ارائه‌ی NET Core 3.0 Preview 7.، اگر <TargetFramework>netcoreapp3.0</TargetFramework> باشد، یعنی در حال استفاده‌ی از C# 8.0 هستید. همچنین پس از ارائه‌ی Preview 8، اگر TargetFramework کتابخانه‌ای به netstandard2.1 تنظیم شود نیز به همین معنا است و نیاز به تنظیمات اضافه‌تری ندارد.
‫۵ سال و ۱ ماه قبل، چهارشنبه ۱۶ مرداد ۱۳۹۸، ساعت ۱۷:۳۲
بهبودهای نوع‌های ارجاعی نال‌نپذیر در NET Core 3.0 Preview 7.

پس از نصب SDK جدید، نحوه‌ی فعالسازی این قابلیت در فایل csproj، به صورت زیر درآمده‌است:
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp3.0</TargetFramework>
    <LangVersion>8.0</LangVersion>
    <Nullable>enable</Nullable>
  </PropertyGroup>
</Project>

این موارد در Preview 7 جدید هستند:
1) امکان اضافه کردن قید جدید notnull در حین تعریف نوع‌های جنریک
    interface IDoStuff<TIn, TOut> where TIn : notnull where TOut : notnull
    {
        TOut DoStuff(TIn input);
    }

2) اضافه شدن یک سری ویژگی توکار جدید برای «پیش» بررسی کار با نوع‌های ارجاعی نال نپذیر

ویژگی AllowNull به فراخوان‌ها امکان ارسال نال را حتی اگر مجاز نباشد، می‌دهد.  این ویژگی جدید در فضای نام System.Diagnostics.CodeAnalysis تعریف شده‌است. برعکس آن ویژگی DisallowNull، سبب خواهد شد تا فراخوان‌ها حتی در صورت مجاز بودن نیز نتوانند نال ارسال کنند.
using System;
using System.Diagnostics.CodeAnalysis;

namespace ConsoleApp
{
    public class MyClass
    {
        private string _innerValue = string.Empty;

        [AllowNull]
        public string MyValue
        {
            get
            {
                return _innerValue;
            }
            set
            {
                _innerValue = value ?? string.Empty;
            }
        }
    }
در مثال فوق ویژگی AllowNull سبب می‌شود تا در قسمت setter امکان دریافت نال نیز میسر شود؛ برای مثال جهت سازگاری با نگارش‌های قبلی برنامه.
دو ویژگی یاد شده را می‌توان بر روی پارامترهای متدها، پارامترهایی از نوع in و ref، فیلدها، خواص و ایندکسرها اعمال کرد.

3) اضافه شدن یک سری ویژگی توکار جدید برای «پس» بررسی کار با نوع‌های ارجاعی نال نپذیر

دو ویژگی جدید MaybeNull و NotNull کار پس بررسی نال پذیری را انجام می‌دهند:
    public class MyArray
    {
        // Result is the default of T if no match is found
        [return: MaybeNull]
        public static T Find<T>(T[] array, Func<T, bool> match)
        {
            //...
        }

        // Never gives back a null when called
        public static void Resize<T>([NotNull] ref T[]? array, int newSize)
        {
            //...
        }
    }
در این مثال، متد Find با تعریف ویژگی return: MaybeNull، ممکن است نال برگرداند. برای مثال اگر چیزی یافت نشد، default را بر گرداند.
در متد Resize، پارامتر array، می‌تواند نال دریافت کند، چون نال‌پذیر تعریف شده‌است؛ اما چون به ویژگی NotNull مزین است، حاصل تغییرات بر روی آن (خروجی از متد، از طریق پارامتری از نوع ref) نمی‌تواند نال باشد.

دو ویژگی یاد شده را می‌توان بر روی خروجی متدها، پارامترهایی از نوع out و ref، فیلدها، خواص و ایندکسرها اعمال کرد.

4) اضافه شدن یک سری ویژگی توکار جدید برای «پس» بررسی «شرطی» کار با نوع‌های ارجاعی نال نپذیر

در مثال‌های زیر کاربردهای دو ویژگی شرطی جدید NotNullWhen و MaybeNullWhen را مشاهده می‌کنید:
    public class MyString
    {
        // True when 'value' is null
        public static bool IsNullOrEmpty([NotNullWhen(false)] string? value)
        {
            //...
        }
    }
در اینجا با بکارگیری ویژگی [NotNullWhen(false)] به فراخوان اعلام می‌کنیم که اگر IsNullOrEmpty مقدار false را بر‌گرداند، مقدار value ارسال شده‌ی به آن، نال نیست.

    public class MyVersion
    {
        // If it parses successfully, the Version will not be null.
        public static bool TryParse(string? input, [NotNullWhen(true)] out Version? version)
        {
            //...
        }
    }
در اینجا با بکارگیری ویژگی [NotNullWhen(true)] به فراخوان اعلام می‌کنیم که اگر TryParse مقدار true را بر‌گرداند، مقدار version خروجی آن، نال نیست.

    public class MyQueue<T>
    {
        // 'result' could be null if we couldn't Dequeue it.
        public bool TryDequeue([MaybeNullWhen(false)] out T result)
        {
            //...
        }
    }
در اینجا با بکارگیری ویژگی [MaybeNullWhen(false)] به فراخوان اعلام می‌کنیم که اگر TryDequeue مقدار false را برگرداند، مقدار result خروجی آن، می‌تواند نال هم باشد.

5) اضافه شدن یک سری ویژگی توکار جدید برای شرط گذاشتن بین ورودی و خروجی، در حین کار با نوع‌های ارجاعی نال نپذیر

در متد زیر، هم خروجی و هم ورودی آن می‌توانند نال باشند. اما می‌خواهیم اگر path نال نباشد، اطمینان حاصل کنیم که استفاده کننده می‌داند، خروجی این متد، حتما نال نخواهد بود:
    class MyPath
    {
        [return: NotNullIfNotNull("path")]
        public static string? GetFileName(string? path)
        {
            //...
        }
    }
برای انجام یک چنین اطلاع رسانی‌هایی می‌توان از ویژگی جدید NotNullIfNotNull استفاده کرد. از آن می‌توان برای مزین سازی خروجی متدها و یا پارامترهایی از نوع ref استفاده کرد.

6) اضافه شدن یک سری ویژگی توکار جدید برای بررسی سیلان برنامه، در حین کار با نوع‌های ارجاعی نال نپذیر

در اینجا نحوه‌ی استفاده از دو ویژگی جدید DoesNotReturn و DoesNotReturnIf را مشاهده می‌کنید:
    internal static class ThrowHelper
    {
        [DoesNotReturn]
        public static void ThrowArgumentNullException(ExceptionArgument arg)
        {
            //...
        }
    }
اگر متد ThrowArgumentNullException در جائی فراخوانی شود، سبب بروز یک استثناء می‌شود. استفاده از DoesNotReturn سبب می‌شود تا به کامپایلر اعلام کند، پس از این نقطه، دیگر نیازی به بررسی نال بودن اشیاء نیست؛ چون آن قطعه از کد، غیرقابل اجرا و رسیدن می‌شود. این ویژگی را تنها بر روی متدها می‌توان قرار داد.

    public static class MyAssertionLibrary
    {
        public static void MyAssert([DoesNotReturnIf(false)] bool condition)
        {
            //...
        }
    }
اگر متد MyAssert فراخوانی شود و ورودی آن false باشد، یک استثناء را صادر می‌کند. با بکارگیری ویژگی [DoesNotReturnIf(false)] این موضوع را به کامپایلر اعلام کرده و از آن درخواست می‌کنیم تا کار بررسی نال بودن اشیاء را از آن سطر به بعد، انجام ندهد. این ویژگی را تنها بر روی پارامترها می‌توان اعمال کرد.
‫۵ سال و ۱ ماه قبل، چهارشنبه ۱۶ مرداد ۱۳۹۸، ساعت ۱۶:۵۶
برای آشنایی با روش استاندارد کش کردن فایل‌های CSS، مراجعه کنید به مطالبی مانند نحوه‌ی افزودن هدر مدت زمان کش شدن آن‌ها (اگر از سرور ویندوزی استفاده می‌کنید، چون مرتبط به IIS است، در اینجا هم معتبر است و تفاوتی نمی‌کند و یا روش چندسکویی آن همان «نکته‌ای در مورد کش کردن فایل‌های استاتیک در ASP.NET Core » است). همچنین tag helper جدید "asp-append-version="true را برای cache-busting آن‌ها (منقضی کردن خودکار کش، با تغییر محتوای فایل) مدنظر داشته باشید.
‫۵ سال و ۱ ماه قبل، چهارشنبه ۱۶ مرداد ۱۳۹۸، ساعت ۰۰:۱۲
ارتقاء به ASP.NET Core 3.0

در کلاس آغازین برنامه‌های وب نگارش 3، بجای متد
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
اینبار متد زیر با معرفی IWebHostEnvironment مشاهده می‌شود (چون این نوع قبلی در دو اسمبلی Microsoft.Extensions.Hosting و Microsoft.AspNetCore.Hosting تعریف شده بوده، جهت رفع ابهام مجبور به این تغییرات شده‌اند):
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
و برای اینکه متدهای الحاقی مانند ()env.IsDevelopment  شناسایی شوند، نیاز به افزودن فضای نام زیر می‌باشد:
using Microsoft.Extensions.Hosting;
البته امضای قبلی، هنوز هم در نگارش 3 کار می‌کند؛ اما در نگارش‌های بعدی حذف خواهد شد.
به صورت خلاصه هرجائی در برنامه‌ی خود IHostingEnvironment دارید، باید به IWebHostEnvironment تبدیل شود. همچنین اگر از سرویس IApplicationLifetime در جائی استفاده کرده‌اید، باید به IHostApplicationLifetime تبدیل گردد.
‫۵ سال و ۱ ماه قبل، سه‌شنبه ۱۵ مرداد ۱۳۹۸، ساعت ۱۹:۵۴
یک نکته‌ی تکمیلی
در NET Core 3.0 Preview 7. امضای این کلاس‌ها و متدها به صورت زیر تغییر کرده‌است و متد Parse به Deserialize تبدیل شده‌است:
namespace System.Text.Json
{
    public static class JsonSerializer
    {
        public static object Deserialize(ReadOnlySpan<byte> utf8Json, Type returnType, JsonSerializerOptions options = null);
        public static object Deserialize(string json, Type returnType, JsonSerializerOptions options = null);
        public static TValue Deserialize<TValue>(ReadOnlySpan<byte> utf8Json, JsonSerializerOptions options = null);
        public static TValue Deserialize<TValue>(string json, JsonSerializerOptions options = null);
        public static object Deserialize(ref Utf8JsonReader reader, Type returnType, JsonSerializerOptions options = null);
        public static TValue Deserialize<TValue>(ref Utf8JsonReader reader, JsonSerializerOptions options = null);
        public static ValueTask<object> DeserializeAsync(Stream utf8Json, Type returnType, JsonSerializerOptions options = null, CancellationToken cancellationToken = default);
        public static ValueTask<TValue> DeserializeAsync<TValue>(Stream utf8Json, JsonSerializerOptions options = null, CancellationToken cancellationToken = default);
        public static string Serialize(object value, Type inputType, JsonSerializerOptions options = null);
        public static string Serialize<TValue>(TValue value, JsonSerializerOptions options = null);
        public static void Serialize(Utf8JsonWriter writer, object value, Type inputType, JsonSerializerOptions options = null);
        public static void Serialize<TValue>(Utf8JsonWriter writer, TValue value, JsonSerializerOptions options = null);
        public static Task SerializeAsync(Stream utf8Json, object value, Type inputType, JsonSerializerOptions options = null, CancellationToken cancellationToken = default);
        public static Task SerializeAsync<TValue>(Stream utf8Json, TValue value, JsonSerializerOptions options = null, CancellationToken cancellationToken = default);
        public static byte[] SerializeToUtf8Bytes(object value, Type inputType, JsonSerializerOptions options = null);
        public static byte[] SerializeToUtf8Bytes<TValue>(TValue value, JsonSerializerOptions options = null);
    }
}
همچنین JsonConverter نیز به تنظیمات آن اضافه شده‌است:
namespace System.Text.Json
{
    public sealed class JsonSerializerOptions
    {
        public JsonSerializerOptions();

        public bool AllowTrailingCommas { get; set; }
        public IList<JsonConverter> Converters { get; }
        public int DefaultBufferSize { get; set; }
        public JsonNamingPolicy DictionaryKeyPolicy { get; set; }
        public bool IgnoreNullValues { get; set; }
        public bool IgnoreReadOnlyProperties { get; set; }
        public int MaxDepth { get; set; }
        public bool PropertyNameCaseInsensitive { get; set; }
        public JsonNamingPolicy PropertyNamingPolicy { get; set; }
        public JsonCommentHandling ReadCommentHandling { get; set; }
        public bool WriteIndented { get; set; }

        public JsonConverter GetConverter(Type typeToConvert);
    }
}
با این تعریف:
namespace System.Text.Json.Serialization
{
    public abstract class JsonConverter
    {
        public abstract bool CanConvert(Type typeToConvert);
    }
}
‫۵ سال و ۱ ماه قبل، سه‌شنبه ۱۵ مرداد ۱۳۹۸، ساعت ۱۳:۳۶
جهت اطلاع
بسته‌ی «Microsoft.AspNetCore.SpaServices» با توجه به وجود ابزارهایی مانند Angular CLI, create-react-app، منسوخ شده اعلام شده و بهتر است یا از آن استفاده نکنید و یا از Microsoft.AspNetCore.SpaServices.Extensions استفاده نمائید.
‫۵ سال و ۱ ماه قبل، دوشنبه ۱۴ مرداد ۱۳۹۸، ساعت ۲۳:۴۵
اگر قسمت «برای اجرای این پروژه» را که اخیرا اضافه شده، مطالعه کنید، مشکلی با اجرای این پروژه نخواهید داشت. آخرین سورس موجود در مخزن کد، کاملا آزمایش شده؛ بدون مشکل کامپایل می‌شود و همچنین قابل اجرا است:

‫۵ سال و ۱ ماه قبل، دوشنبه ۱۴ مرداد ۱۳۹۸، ساعت ۱۶:۴۰
در 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>