‫۵ سال و ۹ ماه قبل، چهارشنبه ۱۴ آذر ۱۳۹۷، ساعت ۲۲:۴۱
خطاهایی که در حین ارتقاء به نگارش 2.2 احتمالا شاهد خواهید بود:

الف) پروژه با خطای زیر بارگذاری نمی‌شود:
Version conflict detected for Microsoft.AspNetCore.Http.Abstractions.
Install/reference Microsoft.AspNetCore.Http.Abstractions 2.2.0 directly to project xyz to resolve this issue.
برای رفع این خطا،
- ابتدا تمام TargetFramework‌های موجود را به 2.2 تغییر دهید.
 <TargetFramework>netcoreapp2.2</TargetFramework>
- پس از آن تمام پوشه‌های bin و obj موجود در تمام پروژه‌های solution جاری را باید یکبار حذف کنید و سپس دستور dotnet restore را صادر کنید. این خطای تداخل نگارش‌ها (Version conflict detected) از وجود پوشه‌های قدیمی bin و obj ناشی می‌شود.
- اکنون نیاز است وابستگی‌های پروژه را نیز یک‌دست کنید:
dotnet tool update --global dotnet-outdated
dotnet outdated -u

ب) اخطار زیر را جهت ذکر صریح شماره نگارش بسته‌ی Microsoft.AspNetCore.App، مشاهده می‌کنید:
A PackageReference to 'Microsoft.AspNetCore.App' specified a Version of `2.2.0`.
Specifying the version of this package is not recommended.
For more information, see https://aka.ms/sdkimplicitrefs
در فایل پروژه، PackageReference این بسته‌ی مخصوص را بدون شماره نگارش ذکر کنید تا همواره به صورت خودکار از آخرین SDK نصب شده استفاده کند:
 <PackageReference Include="Microsoft.AspNetCore.App" />
‫۵ سال و ۹ ماه قبل، دوشنبه ۱۲ آذر ۱۳۹۷، ساعت ۱۴:۱۴
« ... هیچ توکنی در اکشن Logout حذف نخواهد شد ... ».
چندین Remove در TokenStoreService وجود دارند که یکی از آن‌ها مرتبط به RefreshTokenIdHashSource است. مقدار واقعی آن هم در زمان تولید یک Refresh Token جدید تنظیم می‌شود و نه در زمان لاگین. هدف این است که بتوان ردیابی کرد چه توکن جدیدی بر اساس یک Refresh Token قبلی، قابلیت صدور مجدد را پیدا کرده‌است. هدف پیدا کردن والد توکن(های) صادر شده‌ی جدید است. بنابراین اگر عملیات Refresh Token ای صورت نگرفته شده باشد، متد DeleteTokensWithSameRefreshTokenSourceAsync کار خاصی را انجام نخواهد داد.
‫۵ سال و ۹ ماه قبل، پنجشنبه ۸ آذر ۱۳۹۷، ساعت ۱۷:۲۷
جهت اطلاع
امنیت refresh token تولیدی با تبدیل آن به یک JWT بجای صرفا یک Guid ساده، بهبود یافت؛ با این تغییرات. نکته‌های مهم آن دو متد جدید createRefreshToken و getRefreshTokenSerial هستند. در متد جدید getRefreshTokenSerial، کار اعتبارسنجی اطلاعات دریافتی از کاربر نیز صورت می‌گیرد؛ کاری که پیشتر در مورد یک Guid ساده میسر نبود.
‫۵ سال و ۹ ماه قبل، چهارشنبه ۷ آذر ۱۳۹۷، ساعت ۲۳:۲۰
مطلب «معرفی JSON Web Token» را مطالعه کنید تا تفاوت‌های آن با یک Guid مشخص شود (از داشتن امضای دیجیتال جهت اطمینان حاصل کردن از عدم دستکاری آن توسط کاربر، داشتن تاریخ انقضاء تا امکان قرار دادن Claims و نقش‌های کاربر در آن جهت استفاده‌ی در برنامه‌های SPA و ...). به علاوه زمانیکه در اینجا یک زیرساخت استاندارد و آماده‌ی کار با آن و همچنین کاملا آزمایش شده و یک‌دست با تمام اجزای سیستم در ASP.NET Core وجود دارد، اختراع مجدد چرخ، خصوصا در مورد راه حل‌های امنیتی، توصیه نمی‌شود.
‫۵ سال و ۹ ماه قبل، یکشنبه ۴ آذر ۱۳۹۷، ساعت ۰۴:۵۶
بله. از نگارش 4.8.0-beta00005 آن استفاده کنید.
البته در کل « lucenenet » یک سالی هست که پس از ارائه‌ی 4.8.0-beta00005 به روز رسانی نشده‌است. دو علت مهم دارد:
- کسی حاضر نشده این پروژه را پشتیبانی مالی کند.
- اکثر کسانیکه از لوسین استفاده می‌کردند، الان از elastic search استفاده می‌کنند که همیشه آخرین نگارش لوسین اصلی را به همراه دارد. برای مثال حتی مایکروسافت در TFS خود از elastic search استفاده کرده‌است.
دلیل آن مرتبط است به روشی که از آن استفاده کردید. این قابلیت برای اینکه کار کند، نیاز به بافر کردن اطلاعات دارد، در حالیکه شما در حال دانلود یک فایل از یک سایت دیگر هستید. ترکیب این‌ها با هم، برای ارائه‌ی resume کار نمی‌کنند. زمانیکه قرار است قابلیت resume وجود داشته باشد، یعنی مثلا کاربر درخواست دریافت اطلاعات را از بایت 1000 تا 1500، می‌دهد. File Stream Result چطور باید این درخواست را برای httpClient.GetStreamAsync که چنین قابلیتی را ندارد، ترجمه کند؟ اگر می‌خواهید آن‌را برای حالت resume آزمایش کنید، از استریمی از نوع System.IO.File.OpenRead و یا new FileStream استفاده کنید:
public IActionResult FileStreamActionResult()
{
  var fileStream = System.IO.File.OpenRead(@"D:\path\Controllers\HomeController.cs");
  return new FileStreamResult(fileStream, "text/plain") { FileDownloadName = "HomeController.cs" };
}

- بحث جاری مطلقا ارتباطی به Angular ندارد. HttpClient آن بحث دات نتی هست و نه Angular ای.
- در سمت سرور «یک نکته‌ی تکمیلی: پشتیبانی توکار ASP.NET Core 2.0 از Range headers» فوق را با تنظیم پارامتر enableRangeProcessing: true انجام دهید، کافی است و هیچ تغییر دیگری را نیاز ندارد (همان مثال‌های قسمت آخر آن ...به علاوه تمام متدهای بازگشت فایل، پارامتر enableRangeProcessing را نیز به همراه دارند... ).
- در مورد نمایش درصد پیشرفت دانلود و یا آپلود فایل‌ها در برنامه‌های Angular بدون نیاز به کامپوننت جانبی؛ که بدون آن، کاربر باید تا آخرین لحظه‌ی دریافت و یا آپلود بایت‌ها، بدون نمایش گزارشی، صبر کند و شاید اینطور تصور کند که دریافت و یا آپلود یکجا و یکباره بوده‌است: «یک نکته‌ی تکمیلی: به روز رسانی مثال مطلب جاری جهت گزارش درصد پیشرفت آپلود فایل‌ها توسط HTTP Client جدید Angular»
‫۵ سال و ۱۰ ماه قبل، شنبه ۲۶ آبان ۱۳۹۷، ساعت ۲۳:۳۳
بله. فعال سازی Hyper-V سبب از کار افتادن VirtualBox می‌شود و این دو با هم سازگار نیستند (البته با VMWare مشکلی نیست؛ شخصا این مورد را آزمایش کردم). یک نگارش قدیمی‌تر از Docker برای ویندوز، به نام docker toolbox هم وجود دارد که برای اجرای Linux Containers از خود VirtualBox استفاده می‌کند. این روش مشکلات زیر را به همراه دارد:
- docker toolbox یک پروژه‌ی خاتمه یافته و منسوخ شده‌است و مطلقا ویژگی‌های جدید docker را به همراه ندارد.
- فقط و فقط قابلیت اجرای Linux Containers را دارد. برای اجرای Windows Containers تنها راه حل موجود، روشی است که در مطلب جاری بحث شده‌است؛ یعنی استفاده از برنامه‌های Docker For Windows به همراه Hyper-V.
بنابراین اگر نیاز به کار با Docker For Windows و همچنین Virtual Box را دارید، باید به صورت زیر عمل کنید:
الف) نیاز به اجرای Virtual Box است؛ Hyper-V را توسط اجرای دستور زیر با دسترسی ادمین، غیرفعال کنید:
bcdedit /set hypervisorlaunchtype off
ب) نیاز به اجرای Docker for Windows است؛ Hyper-V را توسط اجرای دستور زیر با دسترسی ادمین، فعال کنید:
bcdedit /set hypervisorlaunchtype auto
هر دو دستور، نیاز به ری‌استارت کردن سیستم را هم دارند؛ چون Hyper-V پیش از فعال شدن کرنل ویندوز شروع به کار می‌کند. Hyper-V ویندوز اصطلاحا  Type 1 hyper-visor است و بر روی سخت افزار هاست اجرا می‌شود. اما Virtual Box یا VMWare متفاوت بوده و Type 2 hosted hyper-visor هستند که بر روی OS اجرا می‌شوند.