- اکثر نکات مطلب «اعتبار سنجی اطلاعات ورودی در فرم‌های ASP.NET MVC » در اینجا هم کار می‌کند.
- تفاوتی ندارند. هر دو در نهایت یک کار را انجام می‌دهند. یکی سرویسی را به سیستم اضافه می‌کند. دیگری همان سرویس موجود را با نمونه‌ی جدید سفارشی سازی شده بازنویسی می‌کند.
- سیستم Identity فقط با یک نمونه‌ی از IUserValidator کار می‌کند. 
- اگر چندین پیاده سازی یک اینترفیس را به سیستم تزریق وابستگی‌ها معرفی کنید، استفاده‌ی از آن‌ها نکات خاصی را به همراه دارند که در سری مهارت‌های تزریق وابستگی‌های NET Core. بحث خواهند شد.
- زمانیکه قصد ندارید از IUserValidator پیش‌فرض این سیستم در remote validation خاص یک نقطه‌ی ویژه‌ی برنامه استفاده کنید، نیازی هم به تعریف یا سفارشی سازی آن ندارید. منطق سفارشی خودتان را به هر نحوی که مایل بودید تعریف کنید، چون جای دیگری استفاده نخواهد شد. یک سرویس Validator جدید خاص خودتان را تعریف کنید که دو متد بررسی تعیین اعتبار کاربر یا ایمیل را داشته باشد. سپس این سرویس را به صورت مستقل و جدای از IUserValidator سیستم Identity تزریق و استفاده کنید. دستکاری IUserValidator خود Identity، قسمت‌های دیگر سیستم شما را هم تحت تاثیر قرار خواهد داد.
در نهایت Repository شما وابسته‌است به سرویس DbContext از نوع IDispoable (برای تشکیل یک سرویس، چندین سرویس به صورت خودکار توسط IoC Container وهله سازی می‌شوند). بنابراین برای Dispose صحیح وابستگی‌های تو در توی آن‌ها حتما نیاز است که یک Scope را ایجاد کنید؛ وگرنه این سرویس‌ها و منابع آن‌ها (مانند اتصال گشوده شده‌ی به بانک اطلاعاتی) تا آخر طول عمر برنامه در حافظه باقی خواهند ماند.
در کل برنامه، یک IoC Container‌ بیشتر وجود ندارد. تفاوت ApplicationServices با RequestServices در اصل به وجود یا نبود Scope بر می‌گردد. زمانیکه سرویسی را از ApplicationServices درخواست می‌کنید، مطلقا Scope ای برای آن ایجاد نمی‌شود و اگر مجددا درخواست شود، طول عمر Singleton را مشاهده می‌کنید (مباحث قسمت سوم)، صرف نظر از طول عمر تعریف شده‌ی برای آن سرویس؛ مگر اینکه خودتان به نحوی که توضیح داده شد، یک Scope سفارشی را برای آن ایجاد کنید. اما چون HttpContext.RequestServices داخل یک Scope پیش‌فرض درخواست جاری وب قرار دارد، نیازی به ایجاد صریح Scope را ندارد. البته Scope Validation توضیح داده شده‌ی در مطلب جاری که به ASP.NET Core 2.0 اضافه شده‌است، جلوی اینگونه اشتباهات را با صدور یک استثناء در زمان اجرا می‌گیرد.
این مورد بیشتر به طراحى خود اعتبارسنج این فریم ورک مرتبط هست که همه را یکجا و با هم نیاز دارد. userValidator «کل» اطلاعات شىء کاربر را اعتبارسنجى می‌کند و تمام فیلدهاى آن‌‌را با هم (^ و ^). اگر این مورد مدنظر شما نیست یک remote validation جدید را برای آن طراحی کنید.
‫۵ سال و ۸ ماه قبل، سه‌شنبه ۱۱ دی ۱۳۹۷، ساعت ۲۱:۲۷
- اگر از VS 2017 به روز رسانی نشده استفاده کنید، چون این افزونه از MSBuild آن به صورت پیش‌فرض استفاده می‌کند (یعنی اگر VS 2017 را بر روی سیستم تشخیص دهد، مطلقا از MSBuild به همراه نصاب خودش استفاده نمی‌کند)، مشکلات زیادی را شاهد خواهید بود. یا باید کلا VS 2017 را حذف کنید تا از MSBuild توکار خودش استفاده کند، یا اگر نیاز به VS 2017 دارید، در نصاب آن، گزینه‌ی «NET Core Build Tools" workload."» را انتخاب کنید، تا حداقل این یک مورد را به روز رسانی کند که شامل MSBuild جدید هم هست.
- همچنین نصب آخرین نگارش Dev Pack دات نت و  SDK مخصوص NET Core. را هم فراموش نکنید (هر دو با هم).
‫۵ سال و ۸ ماه قبل، شنبه ۸ دی ۱۳۹۷، ساعت ۱۴:۴۱
- روش IDataProtectionProvider از الگوریتم ویژه‌ای برای تولید عبارت رمزنگاری شده استفاده می‌کند که ممکن است نتیجه‌ی نهایی تولیدی آن با دفعه‌ی قبل فراخوانی آن یکسان نباشد (نتیجه‌ی رمزنگاری آن فقط شامل عبارت رمزنگاری شده نیست و اطلاعات اضافه‌تری را مخصوص این الگویتم دارد). اما هر دو حالت قابل رمزگشایی هستند و در نهایت استفاده کننده مشکلی را مشاهده نخواهد کرد. یعنی مهم نیست که حاصل ویژه‌ی رمزنگاری آن در دوبار فراخوانی پشت سر هم آن یکی نیست. مهم این است که هر دو مورد به علت داشتن اطلاعات ویژه‌ی اضافه‌تری که در عبارت رمزنگاری شده وجود دارد، توسط متد Unprotect آن قابل رمزگشایی هستند.
- اگر نیاز به خروجی رمزنگاری شده‌ی همیشه یکسانی را دارید، از قسمت «معادل الگوریتم Rijndael در NET Core.» استفاده کنید.
‫۵ سال و ۸ ماه قبل، شنبه ۸ دی ۱۳۹۷، ساعت ۰۲:۲۲
متد RegisterGlobalFilters را در این صفحه جستجو کنید. تنظیمی که عنوان کردید، فقط مجموعه‌ی توکار GlobalFilters.Filters را به عنوان پارامتر به آن ارسال می‌کند تا تعدادی فیلتر جدید به لیست آن اضافه شوند.