بحث اصلی مطلب جاری این است که NET Core. (پیاده سازی) با NET Standard. (قرارداد) یکی نیست. NET Core. یکی از پیاده سازی‌های NET Standard. است؛ مانند دات نت 4.6.1 که آن هم پیاده سازی کننده‌ی دات نت استاندارد 2 است. هر دوی این‌ها دارای یک سری API خاص خودشان هم هستند که در NET Standard. وجود ندارند. سطح API دات نت Core هم بیشتر است از NET Standard. و در یکسری از موارد هم کاملا ناسازگار با دات نت کامل. بنابراین توافقی که در اینجا وجود دارد، صرفا پیاده سازی قرارداد NET Standard. است و بیشتر از آن هم مربوط است به توسعه دهندگان آن سکوی کاری خاص که الزامی به یکی بودن آن‌ها نیست.
کاری که پیشتر می‌خواستند انجام دهند، محدود کردن ASP.NET Core به سطح API موجود در NET Core. بود (NET Core 2.0 only. یا تصویر زیر) و نه صرفا به NET Standard. . این مساله برای توسعه دهندگان ASP.NET Core می‌توانست فوق العاده باشد؛ چون سطح API بیشتر و به‌روزتری را در اختیارشان قرار می‌داد و اگر قابلیتی در NET Standard. وجود نداشت، نمی‌بایستی درخواست می‌دادند تا اضافه شود تا بعد بتوانند استفاده کنند.

اما چون این مساله و سطح API بیشتر و گاهی از اوقات کاملا متفاوت، سازگاری با کتابخانه‌هایی را که در میدان دید این API قرار نمی‌گرفتند، زیر سؤال می‌برد، ارتقاء برنامه‌های قبلی را با مشکل مواجه می‌کرد. به همین جهت تصمیم گرفته‌اند که ASP.NET Core را سازگار با دات نت فریم ورک کامل نیز ارائه دهند و بنابراین «محدودش کنند» به NET Standard 2.0.  و نه حالت NET Core only‌. قبلی: اطلاعات بیشتر

به علاوه باید درنظر داشت که امکان اضافه کردن یک بسته‌ی نیوگت از یک کتابخانه‌ی نوشته شده‌ی برای دات نت کامل در برنامه‌های دات نت Core به معنای تضمینی برای کار کردن آن در زمان اجرا نخواهد بود. از این جهت که دات نت کامل، به همراه قسمت‌هایی است که در NET Standard. وجود خارجی ندارند. بنابراین اگر کتابخانه‌ی استفاده شده صرفا این API مشترک را هدف قرار داده‌است، هم قابلیت اتصال و هم قابلیت اجرا را خواهد داشت؛ اما اگر برای مثال کسی بسته‌ی NServiceBus را به پروژه‌ی ASP.NET Core 2.0 اضافه کند، بدون مشکل کامپایل خواهد شد. اما از آنجائیکه این کتابخانه از MSMQ استفاده می‌کند که خارج از میدان دید این استاندارد است، در زمان اجرا با شکست مواجه خواهد شد.

پروژه‌ی ایجاد شده‌ی با قالب استاندارد «dotnet new blazorwasm --hosted --auth individual» از identity server استفاده می‌کند. ما در این سری از روش دیگری استفاده می‌کنیم که کاری به identity server ندارد.

آیا وقتی از identity استفاده میکنیم نیازی هست که از JWT برای تولید توکن و پر کردن claim استفاده کنیم ؟ اگر با identity چنین امکانی وجود داره ممنون میشم در موردش توضیحی بدید . 

توضیح 

از نگارش به روز شده استفاده کنید.

خیر. نگارش سوم structure map تغییراتی داشته که در انتهای مطلب «تزریق خودکار وابستگی‌ها در برنامه‌های ASP.NET Web forms» به صورت یک نکته‌ی تکمیلی مستند شده. مطلب جاری برای نگارش 2.6 تهیه شده بود.

سؤال شما مرتبط است به موضوع "nhibernate derived properties" (+) و برای بررسی مشکل شما نیاز به این موارد است:

- چگونه نگاشت‌ها را تعریف کرده‌اید. (نیاز به سورس است)
- دقیقا چه خطایی می‌گیرید. متن آن‌ خیلی مهم است.

لطفا از امکانات انجمن‌ها برای ادامه‌ی بحث استفاده کنید.

+ اگر از fluent NHibernate استفاده می‌کنید، نگارش سازگار با NHibernate 3 آن هنوز ارائه نشده (به زودی) : (+)

- یک مثال جدید در این مورد اضافه کردم: (^). این مثال با آخرین نگارش موجود در SVN سازگار است.
- و بله. فونت Iranian Sans حاوی حروف انگلیسی نیست. در حالت Html هم استفاده از fallback فونت انگلیسی درنظر گرفته نشده (در خود iTextSharp مساله وجود دارد).
راه حل این است که فونت مورد نظر را صریحا در اینجا ذکر کنید (و این فونت باید در قسمت فونت‌های پیش فرض تعریف شده باشد). مثلا: