‫۶ سال و ۴ ماه قبل، چهارشنبه ۱۹ اردیبهشت ۱۳۹۷، ساعت ۱۵:۰۱
یک نکته‌ی تکمیلی: دریافت خطای «Error RZ3007: Targeted tag name cannot be null or whitespace» پس از نصب SDK جدید

اگر SDK جدیدی را نصب کنید و بلافاصله سعی در اجرای برنامه‌ای که با SDK قبلی کامپایل شده‌است داشته باشید، ممکن است خطای فوق را دریافت کنید. برای رفع آن، ابتدای پوشه‌های bin و obj را حذف کنید. سپس دستور dotnet restore را صادر کنید. اکنون برنامه بدون مشکل اجرا می‌شود.
‫۶ سال و ۴ ماه قبل، چهارشنبه ۱۹ اردیبهشت ۱۳۹۷، ساعت ۰۰:۴۵
جهت اطلاع
پروژه‌ی DNTIdentity به ASP.NET Core 2.1 ارتقاء داده شد.
- مشاهده‌ی لیست کامل تغییرات 

برای اجرای آن فقط کافی است:
- ابتدا SDK جدید را نصب کنید.
- سپس مجوز SSL آن‌را تبدیل به مجوز امن و قابل اطمینان کنید.
- در ادامه به پوشه‌ی DataLayer مراجعه کرده و ابتدا دستور dotnet restore را صادر کنید. بعد از آن دو فایل cmd موجود در آن‌را اجرا کنید. فایل اول مهاجرت‌ها را تولید می‌کند و فایل دوم، آن‌ها را به بانک اطلاعاتی از نوع LocalDB اعمال خواهد کرد. بانک اطلاعاتی تولید شده را در پوشه‌ی wwwroot/App_Data می‌توانید مشاهده کنید.
- در آخر به پوشه‌ی اصلی برنامه مراجعه کرده و دو فایل bat موجود در آن‌را اجرا کنید. اولی وابستگی‌ها را بازیابی می‌کند و دومی برنامه را کامپایل کرده و سپس بر روی پورت SSL 5001 ارائه می‌دهد که بلافاصله در مرورگر قابل مشاهده خواهد بود.

برای اجرای این مراحل نیاز به IDE خاصی ندارید. همینقدر که SDK جدید را نصب کرده باشید، کافی است.  
‫۶ سال و ۴ ماه قبل، سه‌شنبه ۱۸ اردیبهشت ۱۳۹۷، ساعت ۱۶:۲۱
یعنی این Tag Helper سفارشی شناسایی نشده‌است. مطلب «نوشتن TagHelperهای سفارشی برای ASP.NET Core» را مطالعه کنید. قسمت «ثبت و استفاده‌ی از TagHelper سفارشی تهیه شده » انتهای بحث و همچنین «نکته‌ای در مورد نحوه‌ی ثبت TagHelper‌های تهیه شده » در قسمت نظرات.
‫۶ سال و ۴ ماه قبل، سه‌شنبه ۱۸ اردیبهشت ۱۳۹۷، ساعت ۱۴:۵۳
یک نمونه چنین خطایی "Can't resolve stream" در مورد jszip هم هست و پاسخ آن‌ها به این صورت است:
در فایل tsconfig.json این مسیر را باید ذکر کنید:
{
  ...
  "compilerOptions": {
    ...
    "paths": {
      "jszip": [
        "node_modules/jszip/dist/jszip.min.js"
      ]
    }
  }
}
‫۶ سال و ۴ ماه قبل، سه‌شنبه ۱۸ اردیبهشت ۱۳۹۷، ساعت ۱۴:۳۳
- در مورد اینکه چه استثناهایی باید مدیریت شوند یا خیر، مطلب «نکات کار با استثناءها در دات نت» را مطالعه کنید.
- علت عمل نکردن فیلتری که به آن لینک دادید (که من با آن موافق نیستم)، این است که دیگر نباید از میان‌افزار مدیریت استثناهای مخصوص توسعه دهنده‌های ASP.NET Core در این حالت استفاده کنید، چون با آن تداخل می‌کند و پیش از آن وارد عمل می‌شود. علت دریافت صفحه‌ی HTML ایی که مشاهده می‌کنید، همین مورد است. این صفحه برای برنامه‌های ASP.NET Core دارای Viewهای Razor طراحی شده‌است و نه مخصوص حالت کار صرفا Web API آن.
- یکی از مشکلات آن فیلتر هم این است که به هیچ عنوان نباید اصل خطای رخ‌داده‌ی در سمت سرور را به سمت کلاینت ارسال کرد و به کاربر نمایش داد. این مورد امکان دیباگ از راه دور برنامه‌ی شما را توسط یک مهاجم سهولت می‌بخشد و از دیدگاه امنیتی اشتباه است. این موارد را فقط باید توسط امکانات Logging توکار ASP.NET Core ثبت و در سمت سرور با «دسترسی ادمین» بررسی کنید. کاربر هم فقط باید جمله‌ی کلی «خطایی رخ داده‌است» را مشاهده کند و نه جزئیات آن‌را.