دریافت نصاب NET Core 1.1.
برای این منظور به آدرس https://www.microsoft.com/net/download/core مراجعه کرده و فایل NET Core 1.1 SDK - Installer. را دریافت و نصب کنید. برای ظاهر شدن این گزینه باید حالت Current را بجای LTS (Long Term Support) انتخاب کرد:
همچنین در اینجا بسته NET Core 1.1 runtime - Installer. را هم جداگانه میتوان دریافت و نصب کرد.
به روز رسانی فایلهای global.json پروژهها
اولین کاری را که باید پس از نصب نگارشهای جدید NET Core. انجام داد، به روز رسانی شماره نگارش SDK درج شدهی در فایلهای global.json تمام پروژههای موجود است. در غیراینصورت NuGet بستههای جدید مرتبط با آنها را دریافت نخواهد کرد و آنها را در لیست به روز شدهها نخواهید یافت.
برای این منظور خط فرمان را گشوده و دستور ذیل را صادر کنید:
C:\>dotnet --version 1.0.0-preview2-1-003177
{ "projects": [ "src", "test" ], "sdk": { "version": "1.0.0-preview2-1-003177" } }
اصلاح فایل project.json پس از به روز رسانی فایل global.json
در ادامه باید فایل project.json نیز اندکی ویرایش شود تا شماره platform جدید را نیز درج کند. همچنین محل قرارگیری یکسری از بستهها نیز باید تغییر کنند. در غیر اینصورت با اولین کامپایل Solution چنین خطاهایی را دریافت خواهید کرد:
Can not find runtime target for framework '.NETCoreApp,Version=v1.0' compatible with one of the target runtimes: 'win10-x64, win81-x64, win8-x64, win7-x64'. The project does not list one of 'win10-x64, win81-x64, win8-x64, win7-x64' in the 'runtimes' section.
"frameworks": { "netcoreapp1.1": { "dependencies": { "Microsoft.NETCore.App": { "type": "platform", "version": "1.1.0" } }, "imports": [ "dnxcore50", "portable-net45+win8" ] } },
یک نکته: اگر هنوز Microsoft.NETCore.App را در لیست dependencies ابتدای فایل project.json دارید، آنرا حذف کنید؛ چون در قسمت frameworks فوق درج شدهاست. در غیراینصورت پیام تکراری بودن این کلید را دریافت خواهید کرد.
پس از طی دو مرحلهی فوق، یکبار پروژه را بسته و مجددا باز کنید.
به روز رسانی بستههای نیوگت پایدار
قبل از هر کاری مطمئن شوید که آخرین بستهی خود NuGet را نیز نصب کردهاید (مهم). به روز رسانیهای اخیر آن بیشتر در جهت سازگاری با پروژههای NET Core. است.
https://dist.nuget.org/index.html
در ادامه برای به روز رسانی بستههای نیوگت، میتوان بر روی گره References کلیک راست کرد و سپس انتخاب گزینهی Manage NuGet Packages و در آخر انتخاب برگهی Updates و انتخاب کتابخانههای به روز شده. این روش برای حالت داشتن چندین پروژه در یک Solution اندکی کند است.
روش سریعتر که تمام پروژهها را نیز به صورت خودکار بررسی و به روز میکند، مراجعه به کنسول پاورشل نیوگت و سپس صدور دستور ذیل است:
PM> Update-Package
به علاوه پس از پایان کار، یکبار به طور کامل ویژوال استودیو را بسته و مجددا باز کنید. سپس این دستور را یکبار دیگر هم صادر کنید.
به روز رسانی بستههای نیوگت آزمایشی
یکسری از بستهها مانند Microsoft.AspNetCore.Razor.Tools تنها با انتخاب حالت include prereleases ظاهر میشوند که آنها را نیز باید به روز کرد:
تغییر مهم ابزارهای EF Core
در کل Solution عبارت Microsoft.EntityFrameworkCore.Tools را جستجو کرده و با نام جدید Microsoft.EntityFrameworkCore.Tools.DotNet جایگزین کنید.
در آخر یک نمونه فایل project.json به روز شدهی یک برنامهی ASP.NET Core 1.1 را در ذیل مشاهده میکنید:
{ "dependencies": { "Microsoft.AspNetCore.Diagnostics": "1.1.0", "Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore": "1.1.0", "Microsoft.AspNetCore.Http.Extensions": "1.1.0", "Microsoft.AspNetCore.Mvc": "1.1.0", "Microsoft.AspNetCore.Mvc.Core": "1.1.0", "Microsoft.AspNetCore.Mvc.TagHelpers": "1.1.0", "Microsoft.AspNetCore.Razor.Runtime": "1.1.0", "Microsoft.AspNetCore.Razor.Tools": { "version": "1.1.0-preview4-final", "type": "build" }, "Microsoft.AspNetCore.Server.IISIntegration": "1.1.0", "Microsoft.AspNetCore.Server.Kestrel": "1.1.0", "Microsoft.AspNetCore.Session": "1.1.0", "Microsoft.AspNetCore.SpaServices": "1.0.0-beta-000019", "Microsoft.AspNetCore.StaticFiles": "1.1.0", "Microsoft.EntityFrameworkCore": "1.1.0", "Microsoft.EntityFrameworkCore.InMemory": "1.1.0", "Microsoft.EntityFrameworkCore.Tools.DotNet": { "version": "1.1.0-preview4-final", "type": "build" }, "Microsoft.Extensions.Configuration.Binder": "1.1.0", "Microsoft.Extensions.Configuration.Json": "1.1.0", "Microsoft.Extensions.Logging.Console": "1.1.0", "Microsoft.Extensions.Logging.Debug": "1.1.0", "Microsoft.VisualStudio.Web.CodeGeneration.Tools": { "version": "1.1.0-preview4-final", "type": "build" }, "Microsoft.VisualStudio.Web.CodeGenerators.Mvc": { "version": "1.1.0-preview4-final", "type": "build" } }, "tools": { "BundlerMinifier.Core": "2.2.301", "Microsoft.AspNetCore.Razor.Tools": "1.1.0-preview4-final", "Microsoft.VisualStudio.Web.CodeGeneration.Tools": { "version": "1.1.0-preview4-final", "imports": [ "portable-net45+win8" ] }, "Microsoft.EntityFrameworkCore.Tools.DotNet": { "version": "1.1.0-preview4-final", "imports": [ "portable-net45+win8" ] }, "Microsoft.AspNetCore.Server.IISIntegration.Tools": "1.1.0-preview4-final" }, "frameworks": { "netcoreapp1.1": { "dependencies": { "Microsoft.NETCore.App": { "type": "platform", "version": "1.1.0" } }, "imports": [ "dnxcore50", "portable-net45+win8" ] } }, "buildOptions": { "emitEntryPoint": true, "preserveCompilationContext": true }, "runtimeOptions": { "configProperties": { "System.GC.Server": true } }, "publishOptions": { "include": [ "wwwroot", "Features", "appsettings.json", "web.config" ] }, "configurations": { "Release": { "buildOptions": { "optimize": true, "platform": "anycpu" } } }, "scripts": { "precompile": [ "dotnet bundle" ], "prepublish": [ //"bower install" ], "postpublish": [ "dotnet publish-iis --publish-folder %publish:OutputPath% --framework %publish:FullTargetFramework%" ] } }
به روز رسانی پروژهی Test
اگر از MSTest برای انجام آزمونهای واحد استفاده میکنید، تغییرات فایل project.json آن نیز شامل تغییر شماره نگارش NETStandard.Library به 1.6.1 است و همچنین خود بستههای mstest نیز به روز شدهاند. به علاوه قسمت frameworks آن نیز باید همانند مطالبی که عنوان شد، به روز شود:
{ "version": "1.0.0-*", "testRunner": "mstest", "dependencies": { "Microsoft.EntityFrameworkCore": "1.1.0", "Microsoft.EntityFrameworkCore.InMemory": "1.1.0", "NETStandard.Library": "1.6.1", "dotnet-test-mstest": "1.1.2-preview", "MSTest.TestFramework": "1.0.6-preview" }, "frameworks": { "netcoreapp1.1": { "dependencies": { "Microsoft.NETCore.App": { "type": "platform", "version": "1.1.0" } }, "imports": [ "dnxcore50", "portable-net45+win8" ] } } }
The fourth preview of Entity Framework Core (EF Core) 8 is available on NuGet today!
Basic information
EF Core 8, or just EF8, is the successor to EF Core 7, and is scheduled for release in November 2023, at the same time as .NET 8.
EF8 previews currently target .NET 6, and can therefore be used with either .NET 6 (LTS) or .NET 7. This will likely be updated to .NET 8 as we near release.
EF8 will align with .NET 8 as a long-term support (LTS) release. See the .NET support policy for more information.
ASP.NET Core 3.0 Preview 9 منتشر شد
To get started with ASP.NET Core in .NET Core 3.0 Preview 9 install the .NET Core 3.0 Preview 9 SDK.
If you’re on Windows using Visual Studio, install the latest preview of Visual Studio 2019.
.NET Core 3.0 Preview 9 requires Visual Studio 2019 16.3 Preview 3 or later.
کاری که پیشتر میخواستند انجام دهند، محدود کردن ASP.NET Core به سطح API موجود در NET Core. بود (NET Core 2.0 only. یا تصویر زیر) و نه صرفا به NET Standard. . این مساله برای توسعه دهندگان ASP.NET Core میتوانست فوق العاده باشد؛ چون سطح API بیشتر و بهروزتری را در اختیارشان قرار میداد و اگر قابلیتی در NET Standard. وجود نداشت، نمیبایستی درخواست میدادند تا اضافه شود تا بعد بتوانند استفاده کنند.
اما چون این مساله و سطح API بیشتر و گاهی از اوقات کاملا متفاوت، سازگاری با کتابخانههایی را که در میدان دید این API قرار نمیگرفتند، زیر سؤال میبرد، ارتقاء برنامههای قبلی را با مشکل مواجه میکرد. به همین جهت تصمیم گرفتهاند که ASP.NET Core را سازگار با دات نت فریم ورک کامل نیز ارائه دهند و بنابراین «محدودش کنند» به NET Standard 2.0. و نه حالت NET Core only. قبلی: اطلاعات بیشتر
به علاوه باید درنظر داشت که امکان اضافه کردن یک بستهی نیوگت از یک کتابخانهی نوشته شدهی برای دات نت کامل در برنامههای دات نت Core به معنای تضمینی برای کار کردن آن در زمان اجرا نخواهد بود. از این جهت که دات نت کامل، به همراه قسمتهایی است که در NET Standard. وجود خارجی ندارند. بنابراین اگر کتابخانهی استفاده شده صرفا این API مشترک را هدف قرار دادهاست، هم قابلیت اتصال و هم قابلیت اجرا را خواهد داشت؛ اما اگر برای مثال کسی بستهی NServiceBus را به پروژهی ASP.NET Core 2.0 اضافه کند، بدون مشکل کامپایل خواهد شد. اما از آنجائیکه این کتابخانه از MSMQ استفاده میکند که خارج از میدان دید این استاندارد است، در زمان اجرا با شکست مواجه خواهد شد.
داتنت ۷ ریلیز شد!
.NET 7 brings your apps increased performance and new features for C# 11/F# 7, .NET MAUI, ASP.NET Core/Blazor, Web APIs, WinForms, WPF and more. With .NET 7, you can also easily containerize your .NET 7 projects, set up CI/CD workflows in GitHub actions, and achieve cloud-native observability.
Thanks to the open-source .NET community for your numerous contributions that helped shape this .NET 7 release. 28k contributions made by over 8900 contributors throughout the .NET 7 release!
.NET remains one of the fastest, most loved, and trusted platforms with an expansive .NET package ecosystem that includes over 330,000 packages.
کار با کوکیها در ASP.NET Core
مرورگر کروم، از نگارش 80 آن به بعد به همراه یک تغییر غیرسازگار با نگارشهای قبلی آن است: از این پس تمام کوکیهای آن در صورتیکه تنظیمات SameSite را نداشته باشند، به صورت SameSite=Lax تفسیر میشوند؛ که تغییر امنیتی فوق العادهای است و سبب خواهد شد تا بسیاری از حملات مانند CSRF به طور کامل غیرعملی شوند. اما ... این مورد سبب از کار افتادن برنامههایی خواهد شد که از سرویسهایی مانند IdentityServer استفاده میکنند. در یک چنین حالتی نیاز خواهید داشت برای رفع این مشکل، SameSite=None را تنظیم کنید.
اما SameSite چیست؟ تنظیم و خاصیت SameSite از سال 2016 به کوکیها اضافه شد تا بتوان توسط آن در برابر حملات CSRF مقاومت کرد؛ مقادیر اولیهی آن نیز Lax و Strict بودند. Lax به این معنا است که کوکیها در حین مرور یک سایت، باید به صورت خودکار به سمت سرور همان سایت ارسال شوند؛ اما در حالت مرور سایت و هدایت از طریق سایتهای دیگر به سایت ما، فقط درخواستهای GET رسیده میتوانند کوکیها را نیز ارسال کنند. حالت Strict آن فقط کوکیهای تنظیم شدهی درون یک سایت را معتبر شمرده و ارسال میکند. عدم تنظیم SameSite نیز مشکل خاصی را ایجاد نمیکرد. برای مثال اعمال اعتبارسنجی مبتنی بر OpenIdConnect مانند login/logout، نیاز دارند در طی یک درخواست POST، اطلاعاتی را به سایت خارجی درخواست کننده ارسال کنند. برای اینکه این عملیات به درستی صورت گیرد، میبایستی تنظیمات SameSite انجام نمیشد تا جابجایی کوکیها بین دو دومین مختلف در حالت POST، بدون مشکل صورت میگرفت.
وضعیت دات نت در این مورد: با به روز رسانیهای جدید دات نت 4.7.2 و همچنین NET Core 2.1.، مقدار جدید None توسط برنامه (در CookieOptions) قابل تنظیم خواهد بود که سبب تولید SameSite=None میشود. به علاوه در NET Core 3.1.، مقدار SameSite.Unspecified را نیز میتوان تنظیم کرد که سبب خواهد شد تا خاصیت SameSite اصلا تنظیم نشود (اصلا به درخواست اضافه نشود؛ تا مرورگرهایی که نمیتوانند مقدار None را تفسیر کنند، به اشتباه آنرا به Strict تنظیم نکنند).
به صورت خلاصه: اگر برنامهی شما از OpenIdConnect و یا IdentityServer استفاده نمیکند، هیچ تنظیمی را تغییر ندهید! تنظیم پیشفرض SameSite=Lax گوگل سبب میشود تا عملا حملات CSRF دیگر بر روی سایت شما قابل اجرا نباشد. اما اگر از IdentityServer استفاده میکنید، این تنظیم پیشفرض، سبب از کار افتادن امکان ارسال کوکیهای حالت POST، به سایتهای خارجی میشود و برنامه و سیستم شما از کار خواهد افتاد.
قلب سیستم تزریق وابستگیهای NET Core. اینترفیس IServiceProvider است
IServiceProvider که اساس IoC Container برنامههای مبتنی بر NET Core. را تشکیل میدهد، در اسمبلی System.ComponentModel و در فضای نام System تعریف شدهاست:
namespace System { public interface IServiceProvider { object GetService(Type serviceType); } }
استفادهی مستقیم از اینترفیس IServiceProvider برای دسترسی به وهلههای سرویسها، اصطلاحا الگوی Service Locator نامیده میشود و باید تا حد ممکن از آن پرهیز کرد؛ چون وابستگی مستقیمی از IoC Container را درون کدهای ما قرار میدهد و به این ترتیب یک مرحله، نوشتن آزمونهای واحد برای آنرا مشکلتر میکند؛ چون زمان وهله سازی از یک سرویس، دقیقا مشخص نیست به چه وابستگیهایی نیاز دارد. به همین جهت همیشه باید با روش تزریق وابستگیها در سازندهی کلاس شروع کرد و اگر به هر دلیلی این روش مهیا نبود و توسط سیستم تزریق وابستگیهای جاری شناسایی و یا پشتیبانی نمیشد (مانند تزریق وابستگی در سازندههای Attributes)، آنگاه میتوان به الگوی Service Locator مراجعه کرد.
برای مثال در اکثر قسمتهای برنامههای ASP.NET Core امکان تزریق وابستگیها در سازندهی کنترلرها، میان افزارها و سایر اجزای آن وجود دارد و در این حالات نیازی به مراجعهی مستقیم به IServiceProvider برای دریافت وهلههای سرویسهای مورد نیاز نیست. به عبارتی نگرانی در مورد IServiceProvider بهتر است مشکل IoC Container باشد و نه ما.
در مثال زیر، روش استفادهی از IServiceProvider را جهت انجام تزریق وابستگیها (یا به عبارتی بهتر، روش دسترسی به وهلههای وابستگیها) را مشاهده میکنید:
using System; using Microsoft.Extensions.DependencyInjection; using Microsoft.Extensions.Logging; using Microsoft.Extensions.Logging.Abstractions; namespace CoreIocServices { public interface IProductService { void Delete(int id); } public class ProductService : IProductService { private readonly ITestService _testService; private readonly ILogger<ProductService> _logger; public ProductService(IServiceProvider serviceProvider) { _testService = serviceProvider.GetRequiredService<ITestService>(); _logger = serviceProvider.GetService<ILogger<ProductService>>() ?? NullLogger<ProductService>.Instance; } public void Delete(int id) { _testService.Run(); _logger.LogInformation($"Deleted a product with id = {id}"); } } }
- با نگاه کردن به امضای سازندهی این سرویس مشخص نیست که دقیقا از چه وابستگیهایی استفاده میکند. اینکار نوشتن آزمونهای واحد آنرا مشکل میکند.
- این سرویس یک وابستگی اضافهتر را به نام IServiceProvider، نیز پیدا کردهاست که اگر از روش متداول تزریق وابستگیها در سازندهی کلاس استفاده میشد، نیازی به ذکر آن نبود.
- پیاده سازی Dispose Pattern در این حالت مشکلتر است و در قسمتی دیگر بررسی خواهد شد.
تفاوتهای بین متدهای ()<GetService<T و ()<GetRequiredService<T
از آنجائیکه دیگر از NET 1.0. استفاده نمیکنیم، استفادهی از متد GetService با امضایی که در اینترفیس IServiceProvider تعریف شده و strongly typed نیست، بیشتر برای کارهای پویا مناسب است. به همین جهت دو نگارش جنریک از آن در اسمبلی Microsoft.Extensions.DependencyInjection.Abstractions با امضای زیر تعریف شدهاند که نمونهای از آنرا در قسمت قبل نیز استفاده کردیم و برای استفادهی از آنها ذکر فضای نام Microsoft.Extensions.DependencyInjection ضروری است:
namespace Microsoft.Extensions.DependencyInjection { public static class ServiceProviderServiceExtensions { public static T GetRequiredService<T>(this IServiceProvider provider); public static T GetService<T>(this IServiceProvider provider); } }
- متد GetService یک شیء سرویس از نوع T را بازگشت میدهد و یا نال؛ اگر سرویسی از نوع T، پیشتر به سیستم معرفی نشده باشد.
- متد GetRequiredService یک شیء سرویس از نوع T را بازگشت میدهد و یا اگر سرویسی از نوع T پیشتر به سیستم معرفی نشده باشد، استثنای InvalidOperationException را صادر میکند.
بنابراین تنها تفاوت این دو متد، در نحوهی رفتار آنها با درخواست وهلهای از یک سرویس پیشتر ثبت نشدهاست؛ یکی نال را باز میگرداند و دیگری یک استثناء را صادر میکند.
با توجه به این تفاوتها کدامیک از متدهای GetService و یا GetRequiredService را باید استفاده کرد؟
همانطور که پیشتر نیز در توضیحات الگوی Service locator عنوان شد، هیچکدام! ابتدا با تزریق وابستگیهای در سازندهی کلاس شروع کنید و اگر تامین این وابستگی، توسط IoC Container جاری پشتیبانی نمیشد، آنگاه نیاز به استفادهی از یکی از نگارشهای متد GetService خواهد بود و متد توصیه شده نیز GetRequiredService است و نه GetService؛ به این دلایل:
- حذف کدهای تکراری: اگر از GetService استفاده کنید، نیاز خواهید داشت پس از تمام فراخوانیهای آن، بررسی نال بودن آنرا نیز انجام دهید. برای حذف این نوع کدهای تکراری، بهتر است از همان متد GetRequiredService استفاده کنید که به صورت توکار این بررسی را نیز انجام میدهد.
- پشتیبانی از روش Fail Fast و یا همان Defensive programming: اگر بررسی نال بودن GetService را فراموش کنید، در سطرهای بعدی، یافتن علت NullReferenceException صادر شده مشکلتر از رسیدگی به InvalidOperationException صادر شدهی توسط GetRequiredService خواهد بود که توضیحات دقیقی را در مورد سرویس ثبت نشده ارائه میدهد.
- اگر بر روی IoC Container پیشفرض NET Core. یک IoC Container دیگر را مانند AutoFac قرار دادهاید، استفادهی از GetRequiredService، سبب میشود تا اینگونه IoC Containerهای ثالث بتوانند اطلاعات مفیدتری را از سرویسهای ثبت نشده ارائه دهند.
تنها حالتی که استفادهی از روش GetService را نیاز دارد، شرطی کردن ثبت و معرفی کردن سرویسها به IoC Container است؛ اگر سرویسی ثبت شده بود، آنگاه قطعه کدی اجرا شود.
Milestone | Release Date |
---|---|
.NET Core 2.2.x, 2.1.x, 1.x (servicing) | Approximately every 1-2 months or as needed (see also releases) |
.NET Core 3.0 | Preview releases RC (Release Candidate) released in September 2019 (Preview 9) GA (General Availability) released on September 23, 2019 |
.NET Core 3.1 | LTS (Long Term Support) release, scheduled for November 2019 |
.NET 5.0 | Release scheduled for November 2020 |
.NET 6.0 | LTS (Long Term Support) release, scheduled for November 2021 |
.NET 7.0 | Release scheduled for November 2022 |
.NET 8.0 | LTS (Long Term Support) release, scheduled for November 2023 |