نظرات مطالب
سفارشی سازی ASP.NET Core Identity - قسمت اول - موجودیت‌های پایه و DbContext برنامه
مطلب «شروع به کار با EF Core 1.0 - قسمت 2 - به روز رسانی ساختار بانک اطلاعاتی» را مطالعه کنید. صرف تعریف یک خاصیت که کافی نیست. «Invalid column name» یعنی این ستون در بانک اطلاعاتی وجود خارجی ندارد. بنابراین مرحله‌ی بعد، اجرای دستی مهاجرت‌ها است که در اینجا همان اجرای فایل _01-add_migrations.cmd است.
مطالب
بررسی روش ارتقاء به NET Core 1.1.
نگارش پایدار NET Core 1.1. روز قبل منتشر شد. در ادامه نحوه‌ی ارتقاء پروژه‌‌های نگارش 1.0 RTM را به این نگارش بررسی خواهیم کرد.


دریافت نصاب 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
خروجی آن عبارتی است که باید قسمت نگارش SDK درج شود:
{
  "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.
برای رفع این مشکل، عبارت netcoreapp را در Solution جاری جستجو کرده و آن‌ها را به نحو ذیل تغییر دهید:
"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"
            ]
        }
    }
}
اشتراک‌ها
رهانش EF Core 8 Preview 4: Primitive collections and improved Contains

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. 

رهانش  EF Core 8 Preview 4: Primitive collections and improved Contains
اشتراک‌ها
NET Core 3.1. در آذرماه به پایان پشتیبانی خود می‌رسد
The long-term-support (LTS) version 3.1 of Microsoft .NET Core Framework is slated to go out of support on December 13th, 2022. Microsoft recommends upgrading .NET Core 3.1 applications to .NET 6.0 to stay supported for the future, while the developers have mixed feelings about the .NET support policy.
NET Core 3.1. در آذرماه به پایان پشتیبانی خود می‌رسد
نظرات اشتراک‌ها
نگارش بعدی ASP.NET Core از Full .NET Framework پشتیبانی نمی‌کند
بحث اصلی مطلب جاری این است که NET Core. (پیاده سازی) با NET Standard. (قرارداد) یکی نیست. NET Core. یکی از پیاده سازی‌های NET Standard. است؛ مانند دات نت 4.6.1 که آن هم پیاده سازی کننده‌ی دات نت استاندارد 2 است. هر دوی این‌ها دارای یک سری API خاص خودشان هم هستند که در NET Standard. وجود ندارند. سطح API دات نت Core هم بیشتر است از NET Standard. و در یکسری از موارد هم کاملا ناسازگار با دات نت کامل. بنابراین توافقی که در اینجا وجود دارد، صرفا پیاده سازی قرارداد NET Standard. است و بیشتر از آن هم مربوط است به توسعه دهندگان آن سکوی کاری خاص که الزامی به یکی بودن آن‌ها نیست.
کاری که پیشتر می‌خواستند انجام دهند، محدود کردن 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
یک نکته‌ی تکمیلی: ارتقاء به نگارش 3.1 و تغییر تنظیمات کوکی‌ها


مرورگر کروم، از نگارش 80 آن به بعد به همراه یک تغییر غیرسازگار با نگارش‌های قبلی آن است: از این پس تمام کوکی‌های آن در صورتیکه تنظیمات SameSite را نداشته باشند، به صورت SameSite=Lax تفسیر می‌شوند؛ که تغییر امنیتی فوق العاده‌ای است و سبب خواهد شد تا بسیاری از حملات مانند CSRF به طور کامل غیرعملی شوند. اما ... این مورد سبب از کار افتادن برنامه‌هایی خواهد شد که از سرویس‌هایی مانند IdentityServer استفاده می‌کنند. در یک چنین حالتی نیاز خواهید داشت برای رفع این مشکل، SameSite=None را تنظیم کنید.

اما SameSite چیست؟ تنظیم و خاصیت SameSite از سال 2016 به کوکی‌ها اضافه شد تا بتوان توسط آن در برابر حملات CSRF مقاومت کرد؛ مقادیر اولیه‌ی آن نیز Lax و Strict بودند. Lax به این معنا است که کوکی‌ها در حین مرور یک سایت، باید به صورت خودکار به سمت سرور همان سایت ارسال شوند؛ اما در حالت مرور سایت و هدایت از طریق سایت‌های دیگر به سایت ما، فقط درخواست‌های GET رسیده می‌توانند کوکی‌ها را نیز ارسال کنند. حالت Strict آن فقط کوکی‌های تنظیم شده‌ی درون یک سایت را معتبر شمرده و ارسال می‌کند. عدم تنظیم SameSite نیز مشکل خاصی را ایجاد نمی‌کرد. برای مثال اعمال اعتبارسنجی مبتنی بر OpenIdConnect مانند login/logout، نیاز دارند در طی یک درخواست POST، اطلاعاتی را به سایت خارجی درخواست کننده ارسال کنند. برای اینکه این عملیات به درستی صورت گیرد، می‌بایستی تنظیمات SameSite انجام نمی‌شد تا جابجایی کوکی‌ها بین دو دومین مختلف در حالت POST، بدون مشکل صورت می‌گرفت.
با تغییر جدید گوگل، حالت پیش‌فرض SameSite که اجباری نبود، به صورت اجباری به Lax تنظیم شده‌است؛ اما برای حالاتی مانند OpenIdConnect، مقدار None را نیز اضافه کرده‌است. به همین جهت این نوع برنامه‌ها اگر از تنظیم SameSite=None استفاده نکنند، دیگر نمی‌توانند کوکی‌های درخواست‌های POST را بین دومین‌های مختلف جابجا کنند.

مشکل مهم! مقدار None را فقط مرورگر کروم متوجه می‌شود و جزو استاندارد SameSite نیست! در این استاندارد اگر مقدار SameSite تنظیم شود و مرورگر نتواند آن‌را تشخیص دهد (مانند iOS 12)، مقدار Strict را به عنوان مقدار دریافتی تنظیم می‌کند! به همین جهت برنامه‌ی شما باید بر اساس نوع مرورگر تصمیم‌گیری کند که آیا باید SameSite را به خروجی اضافه کند یا خیر.

وضعیت دات نت در این مورد: با به روز رسانی‌های جدید دات نت 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. - قسمت دوم - الگوی Service Locator
در قسمت قبل برای دریافت وهله‌ای از سرویس TestService، به صورت ()<serviceProvider.GetService<ITestService عمل کردیم. این روش در اصل الگوی Service Locator نام دارد که جزئیات بیشتری از آن‌را در این قسمت بررسی خواهیم کرد.


قلب سیستم تزریق وابستگی‌های NET Core. اینترفیس IServiceProvider است

IServiceProvider که اساس IoC Container برنامه‌های مبتنی بر NET Core. را تشکیل می‌دهد، در اسمبلی System.ComponentModel و در فضای نام System تعریف شده‌است:
namespace System
{
    public interface IServiceProvider
    {
        object GetService(Type serviceType);
    }
}
زمانیکه به کمک IServiceCollection، تمام اینترفیس‌ها و کلاس‌های خود را به IoC Container معرفی کردیم، مرحله‌ی بعدی، فراهم آوردن روشی برای دریافت وهله‌ای از این سرویس‌ها توسط متد GetService است.
استفاده‌ی مستقیم از اینترفیس 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}");
        }
    }
}
این روش یا کار مستقیم با Service locator، هر چند کار می‌کند، اما روشی است که باید تا حد ممکن از آن پرهیز کنید؛ زیرا:
- با نگاه کردن به امضای سازنده‌ی این سرویس مشخص نیست که دقیقا از چه وابستگی‌هایی استفاده می‌کند. اینکار نوشتن آزمون‌های واحد آن‌را مشکل می‌کند.
- این سرویس یک وابستگی اضافه‌تر را به نام 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 است؛ اگر سرویسی ثبت شده بود، آنگاه قطعه کدی اجرا شود.
اشتراک‌ها
NET Core 3.1. تا یک ماه دیگر ارائه خواهد شد
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

NET Core 3.1. تا یک ماه دیگر ارائه خواهد شد