در ASP Core برای اتصال به وب سرویس های WCF می توانید از افزونه ی WCF Web Service Provider استفاده کنید.
https://marketplace.visualstudio.com/items?itemName=WCFCORETEAM.VisualStudioWCFConnectedService
https://marketplace.visualstudio.com/items?itemName=WCFCORETEAM.VisualStudioWCFConnectedService
آپدیت سایت های ASP Core
در ASP قدیمی می توانستید سایت در حال کار را مستقیما آپدیت کنید. فقط کافی بود فایلهای جدید را جاگزین فایلهای قبلی کنید. اینکار از طریق FTP یا کپی فایل و Replace کردن ممکن بود. البته روشهای بهتری مثل WebDeploy هم وجود داشت اما از آنجا که خیلی از هاستها از آن پشتیبانی نمی کنند زیاد استفاده نمیشد. دلیل این مسئله وجود قابلیت Shadow Copy در ASP قدیم بود.
در CLR فایلها ی dll مربوط به یک برنامه هنگام اجرا قفل میشود. Shadow Copy از این dll ها یک کپی موقت در محل جدا ذخیره میکند و برنامه را از آنجا اجرا میکند. در نتیجه فایلهای اصلی قفل نمیشوند و می توان آنها را Replace کرد.
در ASP Core هنوز این قابلیت پیاده نشده. برای آپدیت کردن ابتدا باید سایت را stop کنید و بعد کپی کنید. اگر از WebDeploy استفاده کنید عملیات یکسان است اما به صورت خودکار انجام میشود. ضمن اینکه در WebDeploy فایل App_offline در مدت زمان آپدیت جایگزین سایت میشود. البته این گزینه هم فقط برای IIS وجود دارد و در سایر سیستم عاملها پشتیبانی نمیشود.
در ASP قدیمی می توانستید سایت در حال کار را مستقیما آپدیت کنید. فقط کافی بود فایلهای جدید را جاگزین فایلهای قبلی کنید. اینکار از طریق FTP یا کپی فایل و Replace کردن ممکن بود. البته روشهای بهتری مثل WebDeploy هم وجود داشت اما از آنجا که خیلی از هاستها از آن پشتیبانی نمی کنند زیاد استفاده نمیشد. دلیل این مسئله وجود قابلیت Shadow Copy در ASP قدیم بود.
در CLR فایلها ی dll مربوط به یک برنامه هنگام اجرا قفل میشود. Shadow Copy از این dll ها یک کپی موقت در محل جدا ذخیره میکند و برنامه را از آنجا اجرا میکند. در نتیجه فایلهای اصلی قفل نمیشوند و می توان آنها را Replace کرد.
در ASP Core هنوز این قابلیت پیاده نشده. برای آپدیت کردن ابتدا باید سایت را stop کنید و بعد کپی کنید. اگر از WebDeploy استفاده کنید عملیات یکسان است اما به صورت خودکار انجام میشود. ضمن اینکه در WebDeploy فایل App_offline در مدت زمان آپدیت جایگزین سایت میشود. البته این گزینه هم فقط برای IIS وجود دارد و در سایر سیستم عاملها پشتیبانی نمیشود.
چرا Kestrel ؟
فریم ورک ASP Core به نحوی طراحی شده است که روی یک پروسه ی جدا و خارج از IIS اجرا شود. در واقع ASP Core دیگر به wp3wp.exe وابسته نیست.
هدف از این کار یکسان نگه داشتن رفتار سایت فارغ از نوع سیستم عامل است. سیستم عامل های مختلف سرویس دهنده های خودشان را دارند. بجای مطابقت دادن فریم ورک ASP Core با هر کدام از آنها مانند (IIS , Ngnix , Apache ) از Kestrel به عنوان پروکسی معکوس استفاده میشود.
کسترل در مسیر بین ASP Core و سرویس دهنده (IIS , Ngnix , Apache ) قرار میگیرد . هر وقتی درخواستی به سرویس دهنده میرسد مستقیما به Kestrel پاس داده میشود . سپس Kestrel تمامی اطلاعات دریافتی را به شکلی قالب بندی می کند که برای ASP Core قابل تحلیل باشد.(HttpContext)
با این تکنیک تنها کافی است Kestrel با سرویس دهنده های مختلف سازگار شود و کد نویسی برای ASP Core در همه ی پلتفرم ها یکسان است.
فریم ورک ASP Core به نحوی طراحی شده است که روی یک پروسه ی جدا و خارج از IIS اجرا شود. در واقع ASP Core دیگر به wp3wp.exe وابسته نیست.
هدف از این کار یکسان نگه داشتن رفتار سایت فارغ از نوع سیستم عامل است. سیستم عامل های مختلف سرویس دهنده های خودشان را دارند. بجای مطابقت دادن فریم ورک ASP Core با هر کدام از آنها مانند (IIS , Ngnix , Apache ) از Kestrel به عنوان پروکسی معکوس استفاده میشود.
کسترل در مسیر بین ASP Core و سرویس دهنده (IIS , Ngnix , Apache ) قرار میگیرد . هر وقتی درخواستی به سرویس دهنده میرسد مستقیما به Kestrel پاس داده میشود . سپس Kestrel تمامی اطلاعات دریافتی را به شکلی قالب بندی می کند که برای ASP Core قابل تحلیل باشد.(HttpContext)
با این تکنیک تنها کافی است Kestrel با سرویس دهنده های مختلف سازگار شود و کد نویسی برای ASP Core در همه ی پلتفرم ها یکسان است.
چرا Libuv اهمیت دارد ؟
کتابخانه ی Libuv یا Unicorn Velociraptor Library و به معنی "ولوسی رپتور تک شاخ" است. این کتابخانه به زبان C نوشته شده و شامل 30 هزار خط کد میشود. libuv در ابتدا به عنوان هسته ی مرکزی فریم ورک Node.js پیاده شد ولی اکنون توسط بسیاری از فریم ورکهای دیگر مانند Kestrel استفاده میشود.
از آنجا که Kestrel بر پایه ی libuv پیاده شده است و برنامه های ASP Core درون Kestrel اجرا میشوند درک نحوه ی کار libuv برای رمزگشایی از ساختار ASP Core مهم است.
برنامه های ASP Core تنها از یک AppDomain استفاده میکنند و تنها روی یک پروسه اجرا میشوند. درون سیستم عامل یک برنامه ی ASP Core تنها یک Thread را اشغال میکند. نتیجه شاید عجیب باشد اما این تکنیک باعث شده سرعت پردازش اطلاعات نسبت به ASP قدیم بسیار زیاد شود.
کتابخانه ی libuv یک حلقه ی بی نهایت در درونش دارد و بر اساس درخواستها ورودی آنها را طبقه بندی میکند. مثلا تمامی تایمر ها را جدا لیست میکند. درخواستهایی که برای کار با دیتابیس یا فایل هستند در لیست مجزا و محاسبات ریاضی را هم بلافاصله اجرا میکند. در درون هسته libuv از 4 thread استفاده میکند و تنها زمانی آنها را به کار میگیرد که درخواستهای مربوط به فایل و دیتابیس زیادتر از ظرفیت جاری باشد.
این حلقه همیشه در حال اجراست و هیچوقت نمی توان آن را بلاک کرد. هیچ دستوری بلافاصله اجرا نمیشود. بلکه به درون حلقه پرتاپ میشود و طبق یک سری قانون زمان اجرای آن توسط libuv تعیین میشود.
در Node.js حلقه ی اصلی libuv تا حد زیادی ساده شده اما همچنان از همین قانون پیروی میکند. در واقع همه ی دستورات در Node.js به صورت Asyncهستند .
در ASP Core این عملیات به نحوی پیاده شده که دستورات Sync هم قابل اجرا باشند. شما مجبور به استفاده از Async نیستید اما توصیه میشود همیشه و همه جا از Async استفاده کنید چرا که ذات سیستم (Libuv) چنین انتظاری دارد.
کتابخانه ی Libuv یا Unicorn Velociraptor Library و به معنی "ولوسی رپتور تک شاخ" است. این کتابخانه به زبان C نوشته شده و شامل 30 هزار خط کد میشود. libuv در ابتدا به عنوان هسته ی مرکزی فریم ورک Node.js پیاده شد ولی اکنون توسط بسیاری از فریم ورکهای دیگر مانند Kestrel استفاده میشود.
از آنجا که Kestrel بر پایه ی libuv پیاده شده است و برنامه های ASP Core درون Kestrel اجرا میشوند درک نحوه ی کار libuv برای رمزگشایی از ساختار ASP Core مهم است.
برنامه های ASP Core تنها از یک AppDomain استفاده میکنند و تنها روی یک پروسه اجرا میشوند. درون سیستم عامل یک برنامه ی ASP Core تنها یک Thread را اشغال میکند. نتیجه شاید عجیب باشد اما این تکنیک باعث شده سرعت پردازش اطلاعات نسبت به ASP قدیم بسیار زیاد شود.
کتابخانه ی libuv یک حلقه ی بی نهایت در درونش دارد و بر اساس درخواستها ورودی آنها را طبقه بندی میکند. مثلا تمامی تایمر ها را جدا لیست میکند. درخواستهایی که برای کار با دیتابیس یا فایل هستند در لیست مجزا و محاسبات ریاضی را هم بلافاصله اجرا میکند. در درون هسته libuv از 4 thread استفاده میکند و تنها زمانی آنها را به کار میگیرد که درخواستهای مربوط به فایل و دیتابیس زیادتر از ظرفیت جاری باشد.
این حلقه همیشه در حال اجراست و هیچوقت نمی توان آن را بلاک کرد. هیچ دستوری بلافاصله اجرا نمیشود. بلکه به درون حلقه پرتاپ میشود و طبق یک سری قانون زمان اجرای آن توسط libuv تعیین میشود.
در Node.js حلقه ی اصلی libuv تا حد زیادی ساده شده اما همچنان از همین قانون پیروی میکند. در واقع همه ی دستورات در Node.js به صورت Asyncهستند .
در ASP Core این عملیات به نحوی پیاده شده که دستورات Sync هم قابل اجرا باشند. شما مجبور به استفاده از Async نیستید اما توصیه میشود همیشه و همه جا از Async استفاده کنید چرا که ذات سیستم (Libuv) چنین انتظاری دارد.
فایلهای استاتیک در ASP Core
در ASP NET قدیم وظیفه ی پاسخ دادن به درخواست فایل استاتیک بر عهده ی IIS بود. در نتیجه اگر در پروژه ی ASP باگی بوجود می آمد یا برنامه هنگ میکرد فایلهای استاتیک همچنان توسط کاربر قابل مشاهده بود.
در ASP Core این وظیفه به عهده ی یک Middleware است. تمامی درخواستهای مربوط به فایلهای استاتیک به میان افزار StaticFilesMiddleware منتقل میشود . اینکار سرعت پردازش اطلاعات را بالاتر میبرد چون در مواردی که نیاز به فایلهای استاتیک ندارید می توانید تصمیم بگیرید که این میان افزار را از کار بیاندازید . مثلا در وب سرویس ها نیازی به بررسی درخواستهای فایل استاتیک وجود ندارد با حذف این میان افزار می توانید منابع سرور را بیشتر آزاد کنید.
از طرف دیگر حالا اگر برنامه ی ASP Core کرش کند فایلهای استاتیک سایت هم از کار می افتد. راههایی برای دور زدن این مسئله و برگرداندن وظیفه ی مدیریت فایلهای استاتیک به IIS وجود دارد ولی انتخاب پیشفرض ASP Core نیست.
در ASP NET قدیم وظیفه ی پاسخ دادن به درخواست فایل استاتیک بر عهده ی IIS بود. در نتیجه اگر در پروژه ی ASP باگی بوجود می آمد یا برنامه هنگ میکرد فایلهای استاتیک همچنان توسط کاربر قابل مشاهده بود.
در ASP Core این وظیفه به عهده ی یک Middleware است. تمامی درخواستهای مربوط به فایلهای استاتیک به میان افزار StaticFilesMiddleware منتقل میشود . اینکار سرعت پردازش اطلاعات را بالاتر میبرد چون در مواردی که نیاز به فایلهای استاتیک ندارید می توانید تصمیم بگیرید که این میان افزار را از کار بیاندازید . مثلا در وب سرویس ها نیازی به بررسی درخواستهای فایل استاتیک وجود ندارد با حذف این میان افزار می توانید منابع سرور را بیشتر آزاد کنید.
از طرف دیگر حالا اگر برنامه ی ASP Core کرش کند فایلهای استاتیک سایت هم از کار می افتد. راههایی برای دور زدن این مسئله و برگرداندن وظیفه ی مدیریت فایلهای استاتیک به IIS وجود دارد ولی انتخاب پیشفرض ASP Core نیست.
قابلیت های جدید ASP Core 2.1 - Preview
طبق وعده ی تیم ASP Core نسخه ی پیش نمایش 2.1 امروز عرضه شد. حدود 6 هفته ی دیگر نسخه ی پیش نمایش دوم و تا پایان بهار هم نسخه ی 2.1 نهایی عرضه میشود.
طبق روال همیشه نسخه ی های 0.1 بیشتر برای بهبود و تکمیل ایده ها است و تغییرات اساسی را شامل نمیشود. در بسیاری از قسمتها شاهد بهتر شدن تجربه ی کد نویسی هستیم. در ادامه به معرفی بخشی از مهمترین تغییرات این نسخه می پردازیم :
1- ابزار SignalR
تیم ASP Core سخت تلاش میکند همراه با نسخه ی نهایی ابزار SignalR را هم عرضه کند. این ابزار برای ایجاد ارتباط زنده بین کاربران با هم و با سرور استفاده میشود. مثلا اگر نیاز به پیاده سازی یک نرم افزار چت یا بازی های آنلاین دارید این ابزار کار کد نویسی را بسیار ساده میکند.
2- امنیت بیشتر با HTTPS
امنیت یکی از مهمترین نگرانی های امروز است. حالا به پروژه ی پیشفرض ASP Core تنظیمات HTTPS اضافه شده و برای پروژه ی محلی خود هم به راحتی می توانید یک ارتباط امن از نوع HTTPS پیاده کنید و کل پروژه را در آن فضا پیاده و تست کنید.
3- سازگاری با نسخه ی قدیمی دات نت
بعضی از کتابخانه های دات نت در ASP Core وجود ندارد. به این دلیل ساده که پیاده کردن آنها روی همه ی سیستم عاملها بسیار مشکل است. ولی در نسخه ی 2.1 بعضی از کتابخانه های قدیمی مانند Drawing برای استقاده در ویندوز هماهنگ سازی شده. اگر سرور شما ویندوز باشد بدون مشکل می توانید از آنها استفاده کنید.
4- پروژه ی جدا برای Razor UI
در گذشته هم امکان انتقال کنترلرها به کتابخانه های مجزا وجود داشت اما کار پیچیده ای بود. امروز این قابلیت به نحوی اضافه شده که شما به راحتی می توانید هر کنترلر و ویوهای مربوط به آن را به یک پروژه ی جدا منتقل کنید و با اضافه کردن Reference در پروژه اصلی مشاهده کنید. این قابلیت جدید به ASP Core امکان داده که کل بخش Identity را به صورت یک پکیج جدا عرضه کند. دیگر کنترلرها و ویوهای آن را در پروژه مشاهده نمیکنید.
5- بهبود سرور و IIS
گزینه های بیشتری به Kestrel اضافه شده که بیشتر مربوط به امنیت و سرعت میشود همینطور سرعت پردازش اطلاعات برای کار با IIS بسیار بالا رفته است.
6- مدت زمان Build
مدت زمان بیلد شدن پروژه های ASP Core تا بیشتر از نصف شده و این با کمک الگوریتمهای جدید تشخیص تغییرات ممکن شده است.
برای دانلود آخرین نسخه می توانید به آدرس زیر مراجعه کنید اما اگر از ویژوال استودیو استفاده می کنید ابتدا باید آخرین نسخه ی Preview آن را نصب کنید.
https://www.microsoft.com/net/download/all
طبق وعده ی تیم ASP Core نسخه ی پیش نمایش 2.1 امروز عرضه شد. حدود 6 هفته ی دیگر نسخه ی پیش نمایش دوم و تا پایان بهار هم نسخه ی 2.1 نهایی عرضه میشود.
طبق روال همیشه نسخه ی های 0.1 بیشتر برای بهبود و تکمیل ایده ها است و تغییرات اساسی را شامل نمیشود. در بسیاری از قسمتها شاهد بهتر شدن تجربه ی کد نویسی هستیم. در ادامه به معرفی بخشی از مهمترین تغییرات این نسخه می پردازیم :
1- ابزار SignalR
تیم ASP Core سخت تلاش میکند همراه با نسخه ی نهایی ابزار SignalR را هم عرضه کند. این ابزار برای ایجاد ارتباط زنده بین کاربران با هم و با سرور استفاده میشود. مثلا اگر نیاز به پیاده سازی یک نرم افزار چت یا بازی های آنلاین دارید این ابزار کار کد نویسی را بسیار ساده میکند.
2- امنیت بیشتر با HTTPS
امنیت یکی از مهمترین نگرانی های امروز است. حالا به پروژه ی پیشفرض ASP Core تنظیمات HTTPS اضافه شده و برای پروژه ی محلی خود هم به راحتی می توانید یک ارتباط امن از نوع HTTPS پیاده کنید و کل پروژه را در آن فضا پیاده و تست کنید.
3- سازگاری با نسخه ی قدیمی دات نت
بعضی از کتابخانه های دات نت در ASP Core وجود ندارد. به این دلیل ساده که پیاده کردن آنها روی همه ی سیستم عاملها بسیار مشکل است. ولی در نسخه ی 2.1 بعضی از کتابخانه های قدیمی مانند Drawing برای استقاده در ویندوز هماهنگ سازی شده. اگر سرور شما ویندوز باشد بدون مشکل می توانید از آنها استفاده کنید.
4- پروژه ی جدا برای Razor UI
در گذشته هم امکان انتقال کنترلرها به کتابخانه های مجزا وجود داشت اما کار پیچیده ای بود. امروز این قابلیت به نحوی اضافه شده که شما به راحتی می توانید هر کنترلر و ویوهای مربوط به آن را به یک پروژه ی جدا منتقل کنید و با اضافه کردن Reference در پروژه اصلی مشاهده کنید. این قابلیت جدید به ASP Core امکان داده که کل بخش Identity را به صورت یک پکیج جدا عرضه کند. دیگر کنترلرها و ویوهای آن را در پروژه مشاهده نمیکنید.
5- بهبود سرور و IIS
گزینه های بیشتری به Kestrel اضافه شده که بیشتر مربوط به امنیت و سرعت میشود همینطور سرعت پردازش اطلاعات برای کار با IIS بسیار بالا رفته است.
6- مدت زمان Build
مدت زمان بیلد شدن پروژه های ASP Core تا بیشتر از نصف شده و این با کمک الگوریتمهای جدید تشخیص تغییرات ممکن شده است.
برای دانلود آخرین نسخه می توانید به آدرس زیر مراجعه کنید اما اگر از ویژوال استودیو استفاده می کنید ابتدا باید آخرین نسخه ی Preview آن را نصب کنید.
https://www.microsoft.com/net/download/all
Microsoft
Download .NET (Linux, macOS, and Windows) | .NET
Free downloads for building and running .NET apps on Linux, macOS, and Windows. Runtimes, SDKs, and developer packs for .NET Framework, .NET, and ASP.NET.
آشنایی با Race Condition
وضعیت رقابتی یا Race Condition یکی از دلایل اصلی باگ در نرم افزار است و به راحتی می تواند منجر به از کار افتادن برنامه شود. معمولا علت اصلی Race Condition نا همانگی بین داده های ورودی و خروجی است. این ناهماهنگی معمولا به دلیل عدم رعایت حق تقدم در برنامه اتفاق می افتد. هرگاه یک متد قبل یا بعد از زمان پیش بینی شده اجرا شود عملکرد سایر متدهای برنامه را مختل میکند. داده ها به متدهای بعدی ناقص میرسند یا پوچ . متد بعدی ایده ای ندارد که با این داده ها نا معتبر چه کاری انجام دهد در نتیجه برنامه کرش میکند یا خطا روی میدهد.
در بعضی مواقع این کرش کردن می تواند ضررهای جبران ناپذیری به دنبال داشته باشد. در دهه ی 80 میلادی یک دستگاه پرتو درمانی دچار Race Condition شد و چند بیمار Overdose شدند که به مرگ آنها منجر شد. همچنین در مریخ نورد اسپریت وضعیت رقابتی باعث از کار افتادن ماژول عکس برداری شد چون همزمان ماژول دیگری در حال خالی کردن حافظه بود.
هنگامی که مدت زمان اجرای یک متد به طور دقیق مشخص نیست برنامه نویسی برای خروجی مشکل است. فرض کنید یک پست وبلاگ دارید که کاربر همزمان می تواند فایل عکس و ویدیو در فرم آپلود کند. عنوان و متن خیلی سریع در سرور دریافت میشود. عکس بیشتر طول میکشد و بسته به حجم ویدیو زمان نهایی رسیدن اطلاعات به سرور متغیر است. اگر بخواهید اطلاعات فایل عکس و ویدیو را در یک ردیف دیتابیس ذخیره کنید با Race Condition رو برو میشوید.
در بیشتر مواقع Race Condition در برنامه نویسی Async رو میدهد. در این حالت دستورات بلافاصله اجرا نمیشوند بلکه سیستم عامل زمان اجرای آنها را مشخص میکند. شما فقط می توانید رویدادی دریافت کنید که پایان یافتن اجرای متد را گزارش میدهد. به همین دلیل خیلی از برنامه نویسان از Async دوری می کنند یا خیلی از متدها را Lock میکنند تا خروجی را کنترل کنند.
نوشتن برنامه ای که در برابر Race Condition مقاوم باشد آسان نیست. در تست های روزانه نمی توانید آن را مشاهده کنید. RC معمولا در ترافیک بالا و زمانی که منابع سیستم به شدت محدود میشود خود را نشان میدهد. بسته به میزان اهمیت نرم افزار و عواقب ناشی از کرش شدن باید سعی کنید تست های دقیقتری روی برنامه انجام دهید.
وضعیت رقابتی یا Race Condition یکی از دلایل اصلی باگ در نرم افزار است و به راحتی می تواند منجر به از کار افتادن برنامه شود. معمولا علت اصلی Race Condition نا همانگی بین داده های ورودی و خروجی است. این ناهماهنگی معمولا به دلیل عدم رعایت حق تقدم در برنامه اتفاق می افتد. هرگاه یک متد قبل یا بعد از زمان پیش بینی شده اجرا شود عملکرد سایر متدهای برنامه را مختل میکند. داده ها به متدهای بعدی ناقص میرسند یا پوچ . متد بعدی ایده ای ندارد که با این داده ها نا معتبر چه کاری انجام دهد در نتیجه برنامه کرش میکند یا خطا روی میدهد.
در بعضی مواقع این کرش کردن می تواند ضررهای جبران ناپذیری به دنبال داشته باشد. در دهه ی 80 میلادی یک دستگاه پرتو درمانی دچار Race Condition شد و چند بیمار Overdose شدند که به مرگ آنها منجر شد. همچنین در مریخ نورد اسپریت وضعیت رقابتی باعث از کار افتادن ماژول عکس برداری شد چون همزمان ماژول دیگری در حال خالی کردن حافظه بود.
هنگامی که مدت زمان اجرای یک متد به طور دقیق مشخص نیست برنامه نویسی برای خروجی مشکل است. فرض کنید یک پست وبلاگ دارید که کاربر همزمان می تواند فایل عکس و ویدیو در فرم آپلود کند. عنوان و متن خیلی سریع در سرور دریافت میشود. عکس بیشتر طول میکشد و بسته به حجم ویدیو زمان نهایی رسیدن اطلاعات به سرور متغیر است. اگر بخواهید اطلاعات فایل عکس و ویدیو را در یک ردیف دیتابیس ذخیره کنید با Race Condition رو برو میشوید.
در بیشتر مواقع Race Condition در برنامه نویسی Async رو میدهد. در این حالت دستورات بلافاصله اجرا نمیشوند بلکه سیستم عامل زمان اجرای آنها را مشخص میکند. شما فقط می توانید رویدادی دریافت کنید که پایان یافتن اجرای متد را گزارش میدهد. به همین دلیل خیلی از برنامه نویسان از Async دوری می کنند یا خیلی از متدها را Lock میکنند تا خروجی را کنترل کنند.
نوشتن برنامه ای که در برابر Race Condition مقاوم باشد آسان نیست. در تست های روزانه نمی توانید آن را مشاهده کنید. RC معمولا در ترافیک بالا و زمانی که منابع سیستم به شدت محدود میشود خود را نشان میدهد. بسته به میزان اهمیت نرم افزار و عواقب ناشی از کرش شدن باید سعی کنید تست های دقیقتری روی برنامه انجام دهید.