میزان دانلود فریم ورک ReactJS در مقایسه با Angular و VueJS بسیار بیشتر است و عملا می توان گفت گوگل رقابت را به فیس بوک باخته است.
لینک زنده :
https://npmcharts.com/compare/react,@angular/core,vue
لینک زنده :
https://npmcharts.com/compare/react,@angular/core,vue
چرا انگولار محبوبیتش را از دست داد ؟
برای سالها Angular محبوبترین فریم ورک Front-End بود. قابلیت هایی نظیر two-way data binding ، الگوی MVC و تزریق وابستگی در کنار ماژولار بودن کمک کرد تا Angular در بالای لیست قرار گیرد. گوگل تبدیل به حامی انگولار شد و همه چیز خوب پیش میرفت. (سال 2012)
بعد تیم های برنامه نویسی شروع به پیاده سازی پروژه های بزرگ با انگولار کردند. پروژه های بزرگ نقاط ضعف فریم ورک را رو کرد. همه چیز کند کار میکرد و بروز رسانی و تغییر غیر ممکن شد. عیب یابی و دیباگ کردن تبدیل به یک چالش اساسی شد.
در همین زمان برنامه نویسان دیگر با کسب تجربه از ایرادات انگولار شروع به توسعه ی فریم ورکهای جدید کردند.در نتیجه گوگل برای عقب نماندن از دیگران تصمیم گرفت انگولار را از نو پیاده کند.(سال 2014)
تصمیم انگولار به بازنویسی کل فریم ورک بسیاری از برنامه نویسان را آزرده کرد. در همین زمان React که به صورت یک پروژه آزمایشی توسط یکی از کارمندان فیس بوک شروع شده بود توجه ها را به سوی خود جلب کرد. همین نکته بس بود که اپلیکیشن فیس بوک با میلیونها کاربر از React استفاده میکرد. (سال 2013)
انگولار 2 مجموعه از تصمیم های غلط بود و خیلی دیر عرضه شد. برنامه نویسان قبلی علاوه بر یادگیری فریم ورک جدید باید نحوه ی کار با TypeScript را هم فرا میگرفتند. رو آوردن مایکروسافت به React هم بر محبویت آن افزود. بسیاری از سایتهای وابسته به مایکروسافت از React استفاده میکنند با اینکه مایکروسافت خود در پیاده سازی انگولار و TypeScript درگیر بوده است. (سال 2016)
واقعیت این است که Angular 2 بیش از حد کامل است که برای پروژه های بزرگ عالیست اما 80 درصد پروژه ها در دنیای وب این عظمت را ندارند. وقتی پروژه کوچک باشد پیچیدگی ها انگولار در کنار اجبار به استفاده از TypeScript یک مشکل جدی است. هنگامی که از انگولار استفاده میکنید ، باید همه ی آن را استفاده کنید و همه ی کارها را به روش انگولار انجام دهید. استفاده از jQuery یک انتخاب نیست.
انگولار 2 خیلی دیر رسید و وقتی رسید غول بزرگی بود که قدرتش بیش از اندازه زیاد بود. تغییرات زیادی داشت و معلوم نبود چه آینده ای دارد.در نتیجه خیلی از طرفداران انگولار به سنگر React پناه بردند.
برای سالها Angular محبوبترین فریم ورک Front-End بود. قابلیت هایی نظیر two-way data binding ، الگوی MVC و تزریق وابستگی در کنار ماژولار بودن کمک کرد تا Angular در بالای لیست قرار گیرد. گوگل تبدیل به حامی انگولار شد و همه چیز خوب پیش میرفت. (سال 2012)
بعد تیم های برنامه نویسی شروع به پیاده سازی پروژه های بزرگ با انگولار کردند. پروژه های بزرگ نقاط ضعف فریم ورک را رو کرد. همه چیز کند کار میکرد و بروز رسانی و تغییر غیر ممکن شد. عیب یابی و دیباگ کردن تبدیل به یک چالش اساسی شد.
در همین زمان برنامه نویسان دیگر با کسب تجربه از ایرادات انگولار شروع به توسعه ی فریم ورکهای جدید کردند.در نتیجه گوگل برای عقب نماندن از دیگران تصمیم گرفت انگولار را از نو پیاده کند.(سال 2014)
تصمیم انگولار به بازنویسی کل فریم ورک بسیاری از برنامه نویسان را آزرده کرد. در همین زمان React که به صورت یک پروژه آزمایشی توسط یکی از کارمندان فیس بوک شروع شده بود توجه ها را به سوی خود جلب کرد. همین نکته بس بود که اپلیکیشن فیس بوک با میلیونها کاربر از React استفاده میکرد. (سال 2013)
انگولار 2 مجموعه از تصمیم های غلط بود و خیلی دیر عرضه شد. برنامه نویسان قبلی علاوه بر یادگیری فریم ورک جدید باید نحوه ی کار با TypeScript را هم فرا میگرفتند. رو آوردن مایکروسافت به React هم بر محبویت آن افزود. بسیاری از سایتهای وابسته به مایکروسافت از React استفاده میکنند با اینکه مایکروسافت خود در پیاده سازی انگولار و TypeScript درگیر بوده است. (سال 2016)
واقعیت این است که Angular 2 بیش از حد کامل است که برای پروژه های بزرگ عالیست اما 80 درصد پروژه ها در دنیای وب این عظمت را ندارند. وقتی پروژه کوچک باشد پیچیدگی ها انگولار در کنار اجبار به استفاده از TypeScript یک مشکل جدی است. هنگامی که از انگولار استفاده میکنید ، باید همه ی آن را استفاده کنید و همه ی کارها را به روش انگولار انجام دهید. استفاده از jQuery یک انتخاب نیست.
انگولار 2 خیلی دیر رسید و وقتی رسید غول بزرگی بود که قدرتش بیش از اندازه زیاد بود. تغییرات زیادی داشت و معلوم نبود چه آینده ای دارد.در نتیجه خیلی از طرفداران انگولار به سنگر React پناه بردند.
در 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.