چرا 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 معمولا در ترافیک بالا و زمانی که منابع سیستم به شدت محدود میشود خود را نشان میدهد. بسته به میزان اهمیت نرم افزار و عواقب ناشی از کرش شدن باید سعی کنید تست های دقیقتری روی برنامه انجام دهید.
ویوهای Async در Razor
با باز نویسی ASP موتور Razor هم باز نویسی شد و یک تغییر مهم در این بخش Async شدن ویوها است. بخش اصلی کدهای درون یک ویو HTML است که فرقی نکرده است. اما از اینجا به بعد وقتی ASP Core میخواهد محتوای HTML را با کدهای #C ترکیب و خروجی نهایی را ایجاد کند عملیات را به صورت Async انجام میدهد.
اجرای Async یعنی دیگر کدهای #C درون ویو بلافاصله اجرا نمیشوند. این مسئله در حلقه های For یا شرط های IF خودش را نشان نمیدهد. اما در تولید PartialView ها نقش مهمی دارد.
در ASP Core دیگر دستور Html.Action وجود ندارد. به این معنی که دیگر نمی توانید یک اکشن را مستقیما صدا بزنید و خروجی آن را درون ویو جایگزین کنید. این متد یکی از مشکل ساز ترین دستورات MVC5 و ماقبل بود و باعث باگ و ترافیک سنگین سایت میشد.
از آنجا که اکشن ها معمولا با دیتابیس کار میکردند ویو برای تولید نهایی باید منتظر پایان عملیات اکشن میشد. سنگین شدن سرور Race Condition ایجاد میکرد و ویو در نهایت Time Out میشد و کل صفحه را از کار می انداخت.
تولید ویو به صورت Async امکان اجرای موازی اکشن ها را می دهد. با این تفاوت که در ASP Core بجای اکشن از ViewComponent استفاده میشود . View Component نوع خاصی از کنترلر و اکشن است و همیشه به صورت Async اجرا میشود.
با باز نویسی ASP موتور Razor هم باز نویسی شد و یک تغییر مهم در این بخش Async شدن ویوها است. بخش اصلی کدهای درون یک ویو HTML است که فرقی نکرده است. اما از اینجا به بعد وقتی ASP Core میخواهد محتوای HTML را با کدهای #C ترکیب و خروجی نهایی را ایجاد کند عملیات را به صورت Async انجام میدهد.
اجرای Async یعنی دیگر کدهای #C درون ویو بلافاصله اجرا نمیشوند. این مسئله در حلقه های For یا شرط های IF خودش را نشان نمیدهد. اما در تولید PartialView ها نقش مهمی دارد.
در ASP Core دیگر دستور Html.Action وجود ندارد. به این معنی که دیگر نمی توانید یک اکشن را مستقیما صدا بزنید و خروجی آن را درون ویو جایگزین کنید. این متد یکی از مشکل ساز ترین دستورات MVC5 و ماقبل بود و باعث باگ و ترافیک سنگین سایت میشد.
از آنجا که اکشن ها معمولا با دیتابیس کار میکردند ویو برای تولید نهایی باید منتظر پایان عملیات اکشن میشد. سنگین شدن سرور Race Condition ایجاد میکرد و ویو در نهایت Time Out میشد و کل صفحه را از کار می انداخت.
تولید ویو به صورت Async امکان اجرای موازی اکشن ها را می دهد. با این تفاوت که در ASP Core بجای اکشن از ViewComponent استفاده میشود . View Component نوع خاصی از کنترلر و اکشن است و همیشه به صورت Async اجرا میشود.
فایل global.json
فریم ورک dotnet core به شما امکان میدهد چند نسخه آن را همزمان روی سیستم خود نصب کنید. بر خلاف نسخه های قبلی دات نت در Core فایلهای SDK فقط روی سیستم کپی میشوند و تغییراتی روی سیستم عامل بوجود نمی آورند. همه ی نسخه های dotnet روی سیستم خود را می توانید در آدرس C:\Program Files\dotnet\sdk بیابید.
همراه با نصب SDK یک برنامه ی CLI یا Command Line Interface هم نصب میشود و از طریق CMD یا Powershell در همه جای سیستم عامل در دسترس است. این برنامه تمامی دستورات dotnet مانند Build و Run را شامل میشود. معمولا در ویندوز از Visual Studio استفاده می کنید و اصلا متوجه این ابزار نمی شوید. اما در سایر سیستم عامل های مانند Linux و MacOS ابزار CLI تنها راه کامپایل و اجرای برنامه های dotnet core می باشد.
وقتی چند ورژن SDK همزمان روی سیستم نصب باشد CLI همیشه آخرین نسخه ی نصب شده را انتخاب می کند و پروژه ها را با آن میسازد. برای اینکه بدانید کدام ورژن روی سیستم شما فعال است می توانید دستور dotnet - - info را اجرا کنید.
مشکل زمانی پیش می آید که می خواهید از نسخه های قدیمی تر SDK استفاده کنید. در این صورت باید به dotnet بفهمانید که کدام ورژن را برای کار انتخاب کند. اینجاست که فایل global.json اهمیت پیدا میکند. این فایل در هر فولدری قرار گیرد همه ی پروژه های درون آن فولدر و فولدرهای زیرین را به نسخه ی SDK درونش تنظیم میکند. مثلا اگر آن را در ریشه ی درایو قرار دهید و ورژن 1 را در SDK تنظیم کنید تمام پروژه های آن درایو روی نسخه ی 1 کامپایل و اجرا میشوند.
استفاده از global.json وقتی که با نسخه های Preview کار می کنید بسیار مشکل گشاست و به شما کنترل کاملی روی کامپایلر dotnet core میدهد.
فریم ورک dotnet core به شما امکان میدهد چند نسخه آن را همزمان روی سیستم خود نصب کنید. بر خلاف نسخه های قبلی دات نت در Core فایلهای SDK فقط روی سیستم کپی میشوند و تغییراتی روی سیستم عامل بوجود نمی آورند. همه ی نسخه های dotnet روی سیستم خود را می توانید در آدرس C:\Program Files\dotnet\sdk بیابید.
همراه با نصب SDK یک برنامه ی CLI یا Command Line Interface هم نصب میشود و از طریق CMD یا Powershell در همه جای سیستم عامل در دسترس است. این برنامه تمامی دستورات dotnet مانند Build و Run را شامل میشود. معمولا در ویندوز از Visual Studio استفاده می کنید و اصلا متوجه این ابزار نمی شوید. اما در سایر سیستم عامل های مانند Linux و MacOS ابزار CLI تنها راه کامپایل و اجرای برنامه های dotnet core می باشد.
وقتی چند ورژن SDK همزمان روی سیستم نصب باشد CLI همیشه آخرین نسخه ی نصب شده را انتخاب می کند و پروژه ها را با آن میسازد. برای اینکه بدانید کدام ورژن روی سیستم شما فعال است می توانید دستور dotnet - - info را اجرا کنید.
مشکل زمانی پیش می آید که می خواهید از نسخه های قدیمی تر SDK استفاده کنید. در این صورت باید به dotnet بفهمانید که کدام ورژن را برای کار انتخاب کند. اینجاست که فایل global.json اهمیت پیدا میکند. این فایل در هر فولدری قرار گیرد همه ی پروژه های درون آن فولدر و فولدرهای زیرین را به نسخه ی SDK درونش تنظیم میکند. مثلا اگر آن را در ریشه ی درایو قرار دهید و ورژن 1 را در SDK تنظیم کنید تمام پروژه های آن درایو روی نسخه ی 1 کامپایل و اجرا میشوند.
استفاده از global.json وقتی که با نسخه های Preview کار می کنید بسیار مشکل گشاست و به شما کنترل کاملی روی کامپایلر dotnet core میدهد.
پروژه ی نمونه ASP Core
پروژه WebApp از روی قالب خالی پروژه های 2.0 ASP Core ایجاد شده و سرویس MVC و دیتابیس Sqlite با استفاده از تکنیک Code First بهش اضافه شده.
برای دانلود می توانید به آدرس زیر بروید :
https://github.com/codehaks/WebApp
پروژه WebApp از روی قالب خالی پروژه های 2.0 ASP Core ایجاد شده و سرویس MVC و دیتابیس Sqlite با استفاده از تکنیک Code First بهش اضافه شده.
برای دانلود می توانید به آدرس زیر بروید :
https://github.com/codehaks/WebApp
GitHub
codehaks/WebApp
ASP.NET Core Template. Contribute to codehaks/WebApp development by creating an account on GitHub.