HttpClient یک کتابخانه‌ی چندسکویی و پرتابل هست و همه‌جا قابل استفاده‌است. بنابراین ارائه‌ی نحوه‌ی استفاده‌ای که سبب تفکر شود، روش مناسبی برای ارائه‌ی مطلب است. همچنین ممکن است کتابخانه‌هایی را تولید کنید بر همین مبنا که بر اساس NET Standard. تهیه شده باشند و در همه جا (در برنامه‌های WPF تا ASP.NETهای مختلف و غیره) قابل استفاده باشند، به همین جهت یک best practice است که بهتر است رعایت شود.
+ علت‌های استفاده از ConfigureAwait(false):
- جلوگیری از deadlock در برنامه‌های async
بهبود کارآیی برنامه
«... زیرا به علت Restore نشدن Sync Context، عملا مواردی مثل HttpContext.Current مقدار درستی را در خط بعد از await نخواهند داشت ...»
اینطور نیست. درست است که سطرهای پس از ConfigureAwait(false) بر روی Thread pool اجرا می‌شوند که با ترد اصلی شروع کننده‌ی پردازش اکشن متد یکی نیست، اما context اصلی ترد جاری از حفظ اطلاعات مرتبط با ASP.NET در آن‌ها اطمینان حاصل می‌کند:
+ علت‌های استفاده از ConfigureAwait(false):
- جلوگیری از deadlock در برنامه‌های async
بهبود کارآیی برنامه
- با حذف callbackهای فراخوان ترد جاری. هر چقدر تعداد این callbackها کمتر باشد، کارآیی برنامه بیشتر میشود. یک مثال
- با اجازه دادن به 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
