یک نکته‌ی تکمیلی: پشتیبانی توکار ASP.NET Core 2.0 از Range headers

فرض کنید برای آزمایش قسمت «از سرگیری مجدد» دریافت یک فایل حجیم مطلب جاری، یک چنین کدی را در یک برنامه‌ی ASP.NET Core 2.0 تهیه کرده‌اید:
    public class HomeController : Controller
    {
        public IActionResult GetFile()
        {
            return PhysicalFile(@"C:\path\file.pdf", "application/pdf");
        }
در مورد PhysicalFile در مطلب «تغییرات متدهای بازگشت فایل‌ها به سمت کلاینت در ASP.NET Core» بیشتر بحث شده‌است.
اجرای این کد به همراه هدر مخصوص «Accept-Ranges: bytes » که در مطلب جاری در مورد آن بحث شد نیز هست:


یعنی دریافت فایل‌ها در ASP.NET Core 2.0 به صورت توکار از ویژگی «از سرگیری مجدد» پشتیبانی می‌کند. قابلیتی که در نگارش‌های پیشین ASP.NET (تمام نگارش‌های آن‌)، به صورت پیش‌فرض و توکار وجود نداشت و برای پیاده سازی آن می‌بایستی مقدار زیادی کد نوشته می‌شد.
در اینجا return File، FileStreamResult و VirtualFileResult نیز از ویژگی partial range requests پشتیبانی می‌کنند. همچنین حتی اگر از static files middleware آن نیز استفاده کنید، یک چنین قابلیتی را پیاده سازی کرده‌است.
به علاوه تمام متدهای بازگشت فایل، پارامتر enableRangeProcessing را نیز به همراه دارند:
var result = new FileStreamResult(readStream, contentType)
{
                LastModified = lastModified,
                EntityTag = entityTag,
                EnableRangeProcessing = true,
};

 return PhysicalFile(path, "text/plain", "downloadName.txt", lastModified, entityTag, true);

 return File(data, "text/plain", "downloadName.txt", lastModified: null, entityTag: entityTag,
    enableRangeProcessing: true);
‫۶ سال و ۸ ماه قبل، شنبه ۲۳ دی ۱۳۹۶، ساعت ۲۲:۵۲
کار کردن مستقیم با System.Web.HttpContext.Current در یک برنامه‌ی اصولی ASP.NET هیچگاه توصیه نمی‌شود؛ چون نه فقط قابلیت آزمون پذیری آن‌را پایین می‌آورد، همچنین معادل OWIN ایی ندارد و thread-safe هم طراحی نشده‌است. اگر بحث کار با اکشن متدهای ASP.NET MVC 5.x هست، بجای آن از this.HttpContext در یک اکشن متد استفاده می‌شود که پس از ConfigureAwait(false) نال نیست و قابل استفاده است؛ چون این خاصیت عضو کلاس پایه AsyncController هست. برای نمونه اگر قطعه کد اکشن متد Index فوق را در ASP.NET MVC 5.x هم اجرا کنید، کار می‌کند؛ چون  return Content آن در پشت صحنه از همین this.HttpContext برای نوشتن در Response استفاده می‌کند.
‫۶ سال و ۸ ماه قبل، شنبه ۲۳ دی ۱۳۹۶، ساعت ۱۸:۳۹
HttpClient یک کتابخانه‌ی چندسکویی و پرتابل هست و همه‌جا قابل استفاده‌است. بنابراین ارائه‌ی نحوه‌ی استفاده‌ای که سبب تفکر شود، روش مناسبی برای ارائه‌ی مطلب است. همچنین ممکن است کتابخانه‌هایی را تولید کنید بر همین مبنا که بر اساس NET Standard. تهیه شده باشند و در همه جا (در برنامه‌های WPF تا ASP.NET‌های مختلف و غیره) قابل استفاده باشند، به همین جهت یک best practice است که بهتر است رعایت شود.
+ علت‌های استفاده از ConfigureAwait(false):
جلوگیری از deadlock در برنامه‌های async
  بهبود کارآیی برنامه
  1.   با حذف callbackهای فراخوان ترد جاری. هر چقدر تعداد این callbackها کمتر باشد، کارآیی برنامه بیشتر می‌شود. یک مثال
  2.   با اجازه دادن به CLR جهت اجرای این قطعه کد در هر تردی که صلاح می‌داند (و نه اجبار به اجرای نهایی آن در ترد اصلی).

«... زیرا به علت Restore نشدن Sync Context، عملا مواردی مثل HttpContext.Current مقدار درستی را در خط بعد از await نخواهند داشت ...»
اینطور نیست. درست است که سطرهای پس از ConfigureAwait(false) بر روی Thread pool اجرا می‌شوند که با ترد اصلی شروع کننده‌ی پردازش اکشن متد یکی نیست، اما context اصلی ترد جاری از حفظ اطلاعات مرتبط با ASP.NET در آن‌ها اطمینان حاصل می‌کند:

If multiple operations complete at once for the same application, AspNetSynchronizationContext will ensure that they execute one at a time. They may execute on any thread, but that thread will have the identity and culture of the original page

‫۶ سال و ۸ ماه قبل، جمعه ۲۲ دی ۱۳۹۶، ساعت ۱۴:۳۲
یک نکته‌ی تکمیلی: نحوه‌ی ارسال Anti forgery token توسط Action Link ای‌جکسی 

برای اینکار نیاز است متد Ajax begin آن‌را تکمیل کرد:
<a data-ajax="true" data-ajax-begin="onBegin"
در این حالت امضای متد onBegin به صورت ذیل خواهد بود:
<script type=text/javascript>
    function onBegin(xhr, settings) {
        var token = $('input[name=__RequestVerificationToken]').val();
        settings.data = settings.data + '&__RequestVerificationToken=' + token;
    }
</script>
- با تشکر. این نکته اعمال شد.
+ کدهای این سری بر اساس مطلب «نوع‌های نال نپذیر در TypeScript» بازنویسی شده‌اند و کاملا با حالت strictNullChecks سازگاری پیدا کرده‌اند.
همان ذکر آن در CoreModule کافی است. نمونه‌اش ماژول Dashboard استفاده کننده‌ی از این سرویس، در این مثال هست که قسمت providers ایی ندارد. همچنین ذکر SharedModule در قسمت imports آن به‌خاطر استفاده از دایرکتیو is-visible هست.
این خطا مربوط به تزریق وابستگی‌های Location هست. اگر تعریف زیر را فراموش کنید:
import { Location } from "@angular/common";
این Location کامپایل می‌شود، اما از بسته‌ی Angular تامین نخواهد شد.