Kavenegar.Core کلاینت چند سکویی وب سرویس پیامک کاوه نگار برای استفاده در پروژه‌هایی که بر پایه dot net standard و dot net core نوشته شده‌اند.
Ultimate Javascript Object Signing and Encryption (JOSE) and JSON Web Token (JWT) Implementation for .NET and .NET Core
First it is important to recognize that the .NET Framework is not the same as .NET Core. The .NET Framework is effectively now in maintenance mode , and all innovation is occurring in the open source .NET Core now and into the future. So step one to remaining relevant is to understand .NET Core (and the closely related .NET Standard).
The previews of EF Core 5.0 require .NET Standard 2.1. This means:
- EF Core 5.0 runs on .NET Core 3.1; it does not require .NET 5.
- This may change in future previews depending on how the plan for .NET 5 evolves.
- EF Core 5.0 runs on other platforms that support .NET Standard 2.1.
- EF Core 5.0 will not run on .NET Standard 2.0 platforms, including .NET Framework.
Deploy and run .NET Core application without installed runtime. Self-contained applications
Doing a Self-Contained Deployment (SCD) of a .NET Core Application on Ubuntu
Build and Deploy Your ASP.NET Core Application with Apache
Deploying a self contained .Net core application on Linux and run as a daemon process
Self-contained .NET Core Applications
Self Contained .NET Core Applications
How to deploy a self contained .NET Core app
Doing a Self-Contained Deployment (SCD) of a .NET Core Application on Ubuntu
Build and Deploy Your ASP.NET Core Application with Apache
Deploying a self contained .Net core application on Linux and run as a daemon process
Self-contained .NET Core Applications
Self Contained .NET Core Applications
How to deploy a self contained .NET Core app
Day 1 - Installing and Running .NET Core on a Windows Box
Day 2 - Taking a Look at the Visual Studio Templates for .NET Core
Day 3 - Running a .NET Core app on a Mac
Day 4 - Creating a NuGet Package from .NET Core app
Day 5 - Creating a Test Project from .NET Core
Day 6 - Migrating an existing .NET Core to csproj
Day 7 - Creating an ASP.NET Core Web Application
پیشنیازها
- «با HttpHandler بیشتر آشنا شوید»
یکی از بزرگترین تغییرات ASP.NET Core نسبت به نگارش‌های قبلی آن، مدیریت HTTP pipeline آن است. به عنوان یک توسعه دهنده‌ی ASP.NET به طور قطع با مفاهیمی مانند HttpHandler و HttpModules آشنایی دارید و ... هر دوی این‌ها با نگارش جدید ASP.NET حذف و با مفهوم جدیدی به نام Middleware جایگزین شده‌اند.
- HttpHandlerها عموما مبتنی بر پسوندهای فایل‌ها عمل می‌کنند. برای نمونه، رایج‌ترین آن‌ها ASP.NET page handler است که هرگاه درخواستی، ختم شده‌ی به پسوند aspx، به موتور ASP.NET Web forms وارد شد، به این page handler، جهت پردازش نهایی هدایت می‌شود. محل تنظیم آن‌ها نیز در فایل web.config است.
- HttpModuleها مبتنی بر رخدادها عمل می‌کنند. HttpModuleها به عنوان جزئی از request pipeline عمل کرده و دسترسی کاملی دارند به رخدادهای طول عمر درخواست رسیده. آن‌ها را می‌توان توسط فایل‌های global.asax و یا web.config تنظیم کرد.
- MiddleWareها را که جزئی از طراحی OWIN نیز هستند، می‌توان به عنوان کامپوننت‌های کوچکی از برنامه که قابلیت یکپارچه شدن با HTTP request pipeline را دارند، درنظر گرفت. عملکرد آن‌ها ترکیبی است از هر دوی HttpHandler و HttpModuleها که در نگارش‌های قبلی ASP.NET مورد استفاده بودند. از MiddleWareها می‌توان برای پیاده سازی اعمال مختلفی جهت پردازش درخواست‌های رسیده مانند اعتبارسنجی، کار با سشن‌ها، ثبت وقایع سیستم، مسیریابی و غیره استفاده کرد. OWIN یا Open Web Interface for .NET به توسعه دهنده‌ها امکان غیروابسته کردن برنامه‌ی ASP.NET خود را از وب سرور مورد استفاده می‌دهد. به علاوه OWIN امکان پلاگین نویسی اجزای مختلف برنامه را بدون وابسته کردن آن‌ها به یکدیگر فراهم می‌کند. برای مثال می‌توان یک پلاگین logger را تهیه کرد تا اطلاعات مختلفی را از درخواست‌های رسیده ثبت کند.
مواردی که با ارائه‌ی ASP.NET Core 1.0 حذف شده‌اند
- System.Web: یکی از اهداف اصلی OWIN، مستقل کردن برنامه‌ی وب، از هاست آن است تا بتوان از وب سرورهای بیشتری استفاده کرد. System.Web انحصارا برای IIS طراحی شده بود و در این نگارش دیگر وجود خارجی ندارد.
- HttpModules: با Middlewareها جایگزین شده‌اند.
- HttpHandlers: البته HttpHandlers از زمان ارائه‌ی اولین نگارش ASP.NET MVC، در چندین سال قبل منسوخ شدند. زیرا پردازش صفحات وب در ASP.NET MVC برخلاف وب فرم‌ها، از فایل‌هایی با پسوندهای خاص شروع نمی‌شوند و نقطه‌ی آغازین آن‌ها، اکشن متدهای کنترلرها است.
- فایل global.asax: با حذف شدن HttpModules، دیگر ضرورتی به وجود این فایل نیست.
شباهت‌های بینMiddleware و HttpModuleها
همانند HttpModuleها، Middlewareها نیز به ازای هر درخواست رسیده اجرا می‌شوند و از هر دو می‌توان جهت تولید response ایی خاص استفاده کرد.
تفاوت‌های بینMiddleware و HttpModuleها
- عموما HttpModule از طریق web.config و یا فایل global.asax تنظیم می‌شوند. اما Middlewareها تنها از طریق کد و در فایل Startup.cs برنامه‌های ASP.NET Core 1.0 قابل معرفی هستند.
- به عنوان یک توسعه دهنده، کنترلی را بر روی ترتیب اجرای انواع و اقسام HttpModuleها نداریم. این مشکل در Middlewareها برطرف شده و اکنون ترتیب اجرای آن‌ها، دقیقا مطابق ترتیب افزوده شدن و تعریف آن‌ها در فایل Startup.cs است.
- ترتیب اجرای HttpModuleها هرچه که باشد، برای حالت‌های request و response یکی است. اما ترتیب اجرای Middlewareهای مخصوص response، عکس ترتیب اجرای Middlewareهای مخصوص request هستند (تصویر ذیل).
- HttpModuleها را صرفا جهت اتصال کدهایی به رخدادهای طول عمر برنامه می‌توان طراحی کرد؛ اما Middleware مستقل هستند از این رخدادها.
- HttpModuleها به System.Web وابسته‌اند؛ برخلاف Middlewareها که وابستگی به هاست خود ندارند.
Middlewareهای توکار ASP.NET Core 1.0
ASP.NET Core 1.0 به همراه تعدادی Middleware توکار است؛ مانند:
- Authentication: جهت پشتیبانی از اعتبارسنجی
- CORS: برای فعال سازی Cross-Origin Resource Sharing
- Routing: جهت تعریف و محدود سازی مسیریابی‌های برنامه
- Session: برای پشتیبانی و مدیریت سشن‌های کاربران
- Diagnostics: پشتیبانی از صفحات خطا و اطلاعات زمان اجرای برنامه
و مواردی دیگر که برای توزیع فایل‌های استاتیک و یا مرور محتویات پوشه‌ها و امثال آن‌ها طراحی شده‌اند که در طی این مطلب و همچنین مطالب آتی، آن‌ها را بررسی خواهیم کرد.
یک مثال: اگر یک پروژه‌ی خالی ASP.NET Core 1.0 را در ویژوال استودیو ایجاد کنید، این پروژه قادر نیست حتی فایل‌های استاتیک مانند تصاویر، فایل‌های پیش فرض مانند index.html و یا قابلیت مرور ساده‌ی فایل‌های موجود در یک پوشه را ارائه دهد (حتی اگر به آن‌ها نیازی نداشته باشید).
طراحی این نگارش از ASP.NET، مبتنی است بر سبک وزن بودن و ماژولار بودن. هر قابلیتی را که نیاز دارید، باید middleware آن‌را نیز خودتان به صورت صریح اضافه کنید و یا در غیر اینصورت فعال نیست. برخلاف نگارش‌های قبلی ASP.NET که HTTP Moduleهای از سشن گرفته تا اعتبارسنجی و غیره، همگی به صورت پیش فرض در فایل Web.Config فعال بودند؛ مگر اینکه آن‌ها را به صورت دستی حذف می‌کردید.
ثبت و فعال سازی اولین Middleware
در ادامه‌ی تکمیل و معرفی برنامه‌ی خالی ASP.NET Core 1.0، قصد داریم یک Middleware توکار را به نام Welcome Page، بجای نمایش سطر Hello world پیش فرض این برنامه، ثبت و فعال سازی کنیم. این Middleware ویژه، در اسمبلی به نام Microsoft.AspNetCore.Diagnostics قرار دارد. اگر فایل project.json پیش فرض این پروژه را باز کنید، این اسمبلی به صورت پیش فرض در آن ثبت و معرفی شده‌است:
بنابراین هم اکنون بسته‌ی نیوگت آن نیز به پروژه‌ی جاری اضافه شده و قابل استفاده است. در غیراینصورت همانطور که در قسمت قبل در مطلب «نقش فایل project.json» عنوان شد، می‌توان بر روی گره references کلیک راست کرده و سپس از منوی ظاهر شده،گزینه‌ی manage nuget packages را انتخاب کرد. سپس، ابتدا برگه‌ی browse را انتخاب کنید و در اینجا نام Microsoft.AspNetCore.Diagnostics را جستجو کرده و در آخر آن‌را نصب کنید.
پس از اطمینان حاصل کردن از نصب بسته‌ی نیوگت Microsoft.AspNetCore.Diagnostics، اکنون جهت معرفی Middleware توکار Welcome Page ، فایل Startup.cs را گشوده و کدهای آن‌را به نحو ذیل تغییر دهید:
در اینجا نحوه‌ی ثبت این middleware را با افزودن آن به IApplicationBuilder تزریق شده‌ی توسط OWIN، به کمک متد الحاقی UseWelcomePage مشاهده می‌کنید.
به علاوه middleware دومی را نیز با متد الحاقی Run مشاهده می‌کنید. به این نوع middlewareهای خاص، اصطلاحا terminal middleware می‌گویند. از این جهت که درخواستی را دریافت و یک response را تولید می‌کنند و کار همینجا خاتمه می‌یابد و زنجیره‌ی پردازشی middlewareها ادامه نخواهد یافت. در اینجا پارامتر context آن از نوع HttpContext است و باید دقت داشت، زمانیکه کار نوشتن در Response، در اینجا انجام شد، اگر پس از متد Run یک Middleware دیگر را ثبت کنید، هیچگاه اجرا نخواهد شد.
در این حالت اگر برنامه را اجرا کنید، خروجی ذیل را مشاهده خواهید کرد:
welcome page نیز یک terminal middleware است. به همین جهت middleware بعدی ثبت شده‌ی در اینجا یا همان متد Run، دیگر اجرا نخواهد شد.
در قسمت‌های بعدی، تعداد بیشتری از Middlewareهای توکار ASP.NET Core 1.0 را بررسی خواهیم کرد.
- «با HttpHandler بیشتر آشنا شوید»
یکی از بزرگترین تغییرات ASP.NET Core نسبت به نگارش‌های قبلی آن، مدیریت HTTP pipeline آن است. به عنوان یک توسعه دهنده‌ی ASP.NET به طور قطع با مفاهیمی مانند HttpHandler و HttpModules آشنایی دارید و ... هر دوی این‌ها با نگارش جدید ASP.NET حذف و با مفهوم جدیدی به نام Middleware جایگزین شده‌اند.
- HttpHandlerها عموما مبتنی بر پسوندهای فایل‌ها عمل می‌کنند. برای نمونه، رایج‌ترین آن‌ها ASP.NET page handler است که هرگاه درخواستی، ختم شده‌ی به پسوند aspx، به موتور ASP.NET Web forms وارد شد، به این page handler، جهت پردازش نهایی هدایت می‌شود. محل تنظیم آن‌ها نیز در فایل web.config است.
- HttpModuleها مبتنی بر رخدادها عمل می‌کنند. HttpModuleها به عنوان جزئی از request pipeline عمل کرده و دسترسی کاملی دارند به رخدادهای طول عمر درخواست رسیده. آن‌ها را می‌توان توسط فایل‌های global.asax و یا web.config تنظیم کرد.
- MiddleWareها را که جزئی از طراحی OWIN نیز هستند، می‌توان به عنوان کامپوننت‌های کوچکی از برنامه که قابلیت یکپارچه شدن با HTTP request pipeline را دارند، درنظر گرفت. عملکرد آن‌ها ترکیبی است از هر دوی HttpHandler و HttpModuleها که در نگارش‌های قبلی ASP.NET مورد استفاده بودند. از MiddleWareها می‌توان برای پیاده سازی اعمال مختلفی جهت پردازش درخواست‌های رسیده مانند اعتبارسنجی، کار با سشن‌ها، ثبت وقایع سیستم، مسیریابی و غیره استفاده کرد. OWIN یا Open Web Interface for .NET به توسعه دهنده‌ها امکان غیروابسته کردن برنامه‌ی ASP.NET خود را از وب سرور مورد استفاده می‌دهد. به علاوه OWIN امکان پلاگین نویسی اجزای مختلف برنامه را بدون وابسته کردن آن‌ها به یکدیگر فراهم می‌کند. برای مثال می‌توان یک پلاگین logger را تهیه کرد تا اطلاعات مختلفی را از درخواست‌های رسیده ثبت کند.
مواردی که با ارائه‌ی ASP.NET Core 1.0 حذف شده‌اند
- System.Web: یکی از اهداف اصلی OWIN، مستقل کردن برنامه‌ی وب، از هاست آن است تا بتوان از وب سرورهای بیشتری استفاده کرد. System.Web انحصارا برای IIS طراحی شده بود و در این نگارش دیگر وجود خارجی ندارد.
- HttpModules: با Middlewareها جایگزین شده‌اند.
- HttpHandlers: البته HttpHandlers از زمان ارائه‌ی اولین نگارش ASP.NET MVC، در چندین سال قبل منسوخ شدند. زیرا پردازش صفحات وب در ASP.NET MVC برخلاف وب فرم‌ها، از فایل‌هایی با پسوندهای خاص شروع نمی‌شوند و نقطه‌ی آغازین آن‌ها، اکشن متدهای کنترلرها است.
- فایل global.asax: با حذف شدن HttpModules، دیگر ضرورتی به وجود این فایل نیست.
شباهت‌های بینMiddleware و HttpModuleها
همانند HttpModuleها، Middlewareها نیز به ازای هر درخواست رسیده اجرا می‌شوند و از هر دو می‌توان جهت تولید response ایی خاص استفاده کرد.
تفاوت‌های بینMiddleware و HttpModuleها
- عموما HttpModule از طریق web.config و یا فایل global.asax تنظیم می‌شوند. اما Middlewareها تنها از طریق کد و در فایل Startup.cs برنامه‌های ASP.NET Core 1.0 قابل معرفی هستند.
- به عنوان یک توسعه دهنده، کنترلی را بر روی ترتیب اجرای انواع و اقسام HttpModuleها نداریم. این مشکل در Middlewareها برطرف شده و اکنون ترتیب اجرای آن‌ها، دقیقا مطابق ترتیب افزوده شدن و تعریف آن‌ها در فایل Startup.cs است.
- ترتیب اجرای HttpModuleها هرچه که باشد، برای حالت‌های request و response یکی است. اما ترتیب اجرای Middlewareهای مخصوص response، عکس ترتیب اجرای Middlewareهای مخصوص request هستند (تصویر ذیل).
- HttpModuleها را صرفا جهت اتصال کدهایی به رخدادهای طول عمر برنامه می‌توان طراحی کرد؛ اما Middleware مستقل هستند از این رخدادها.
- HttpModuleها به System.Web وابسته‌اند؛ برخلاف Middlewareها که وابستگی به هاست خود ندارند.
Middlewareهای توکار ASP.NET Core 1.0
ASP.NET Core 1.0 به همراه تعدادی Middleware توکار است؛ مانند:
- Authentication: جهت پشتیبانی از اعتبارسنجی
- CORS: برای فعال سازی Cross-Origin Resource Sharing
- Routing: جهت تعریف و محدود سازی مسیریابی‌های برنامه
- Session: برای پشتیبانی و مدیریت سشن‌های کاربران
- Diagnostics: پشتیبانی از صفحات خطا و اطلاعات زمان اجرای برنامه
و مواردی دیگر که برای توزیع فایل‌های استاتیک و یا مرور محتویات پوشه‌ها و امثال آن‌ها طراحی شده‌اند که در طی این مطلب و همچنین مطالب آتی، آن‌ها را بررسی خواهیم کرد.
یک مثال: اگر یک پروژه‌ی خالی ASP.NET Core 1.0 را در ویژوال استودیو ایجاد کنید، این پروژه قادر نیست حتی فایل‌های استاتیک مانند تصاویر، فایل‌های پیش فرض مانند index.html و یا قابلیت مرور ساده‌ی فایل‌های موجود در یک پوشه را ارائه دهد (حتی اگر به آن‌ها نیازی نداشته باشید).
طراحی این نگارش از ASP.NET، مبتنی است بر سبک وزن بودن و ماژولار بودن. هر قابلیتی را که نیاز دارید، باید middleware آن‌را نیز خودتان به صورت صریح اضافه کنید و یا در غیر اینصورت فعال نیست. برخلاف نگارش‌های قبلی ASP.NET که HTTP Moduleهای از سشن گرفته تا اعتبارسنجی و غیره، همگی به صورت پیش فرض در فایل Web.Config فعال بودند؛ مگر اینکه آن‌ها را به صورت دستی حذف می‌کردید.
ثبت و فعال سازی اولین Middleware
در ادامه‌ی تکمیل و معرفی برنامه‌ی خالی ASP.NET Core 1.0، قصد داریم یک Middleware توکار را به نام Welcome Page، بجای نمایش سطر Hello world پیش فرض این برنامه، ثبت و فعال سازی کنیم. این Middleware ویژه، در اسمبلی به نام Microsoft.AspNetCore.Diagnostics قرار دارد. اگر فایل project.json پیش فرض این پروژه را باز کنید، این اسمبلی به صورت پیش فرض در آن ثبت و معرفی شده‌است:
{
"dependencies": {
"Microsoft.NETCore.App": {
"version": "1.0.0",
"type": "platform"
},
"Microsoft.AspNetCore.Diagnostics": "1.0.0",
"Microsoft.AspNetCore.Server.IISIntegration": "1.0.0",
"Microsoft.AspNetCore.Server.Kestrel": "1.0.0",
"Microsoft.Extensions.Logging.Console": "1.0.0"
}, پس از اطمینان حاصل کردن از نصب بسته‌ی نیوگت Microsoft.AspNetCore.Diagnostics، اکنون جهت معرفی Middleware توکار Welcome Page ، فایل Startup.cs را گشوده و کدهای آن‌را به نحو ذیل تغییر دهید:
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.DependencyInjection;
namespace Core1RtmEmptyTest
{
public class Startup
{
public void ConfigureServices(IServiceCollection services)
{
}
public void Configure(IApplicationBuilder app)
{
app.UseWelcomePage();
app.Run(async (context) =>
{
await context.Response.WriteAsync("Hello DNT!");
});
}
}
} به علاوه middleware دومی را نیز با متد الحاقی Run مشاهده می‌کنید. به این نوع middlewareهای خاص، اصطلاحا terminal middleware می‌گویند. از این جهت که درخواستی را دریافت و یک response را تولید می‌کنند و کار همینجا خاتمه می‌یابد و زنجیره‌ی پردازشی middlewareها ادامه نخواهد یافت. در اینجا پارامتر context آن از نوع HttpContext است و باید دقت داشت، زمانیکه کار نوشتن در Response، در اینجا انجام شد، اگر پس از متد Run یک Middleware دیگر را ثبت کنید، هیچگاه اجرا نخواهد شد.
در این حالت اگر برنامه را اجرا کنید، خروجی ذیل را مشاهده خواهید کرد:
welcome page نیز یک terminal middleware است. به همین جهت middleware بعدی ثبت شده‌ی در اینجا یا همان متد Run، دیگر اجرا نخواهد شد.
در قسمت‌های بعدی، تعداد بیشتری از Middlewareهای توکار ASP.NET Core 1.0 را بررسی خواهیم کرد.
یک نکته‌ی تکمیلی
بجای NBench، این‌روزها BenchmarkDotNet تبدیل به استانداردی برای اندازه‌گیری کارآیی برنامه‌های دات نت شده‌است. چند نمونه مثال از کاربرد آن توسط تیم‌های مایکروسافت جهت اندازه‌گیری کارآیی قسمت‌های مختلف NET Core.:
جهت اطلاع
این تصمیم به صورت رسمی لغو شده‌است:
این تصمیم به صورت رسمی لغو شده‌است:
Edit: the "no .NET Framework support for ASP.NET Core 2.0" plan
has been officially cancelled and running ASP.NET Core 2.0 on .NET
Desktop will be supported in the next previews. For more information, read Announcing ASP.NET Core 2.0.0-Preview1 and Updates for .NET Web Developers or watch .NET Standard 2.0 and .NET Core 2.0.
عموما برنامه‌های بزرگ NET.، به چندین زیر پروژه شکسته می‌شوند تا مدیریت آن‌ها ساده‌تر شود. مهم‌ترین مشکلی که در این حالت پس از مدتی بروز می‌کند، هماهنگ نگه داشتن شماره نگارش‌های ارجاعات NuGet این پروژه‌ها است و همچنین به روز رسانی مکرر و هر باره‌ی تمام این فایل‌های csproj. به همین جهت ایده‌ی مدیریت مرکزی شماره نگارش‌های ارجاعات پروژه‌های NuGet قرار است به نگارش بعدی آن اضافه شود که البته هم اکنون نیز قسمتی از آن در NET Core SDK 3.1.300. به بعد، قابل استفاده‌است که جزئیات آن‌را در ادامه مرور می‌کنیم.
ایجاد فایل جدید Directory.Packages.props
زمانیکه قرار است شماره نگارش‌های بسته‌های NuGet مختلف مورد استفاده‌ی در برنامه، به صورت مرکزی مدیریت شوند، نیاز به یک مخزن ثبت آن‌ها نیز می‌باشد. به همین جهت یک فایل جدید را به نام Directory.Packages.props در کنار فایل sln پروژه‌ی خود ایجاد کنید (در ریشه‌ی اصلی پروژه)؛ با این محتوای فرضی:
برای تشکیل این فایل، فایل‌های csproj مختلف موجود در solution جاری را یافته و سپس PackageReferenceهای آن‌ها را به فایل props فوق کپی کنید؛ با یک تفاوت مهم: بجای PackageReference اینبار از نام PackageVersion استفاده می‌شود.
تغییرات مورد نیاز در فایل‌های پروژه‌های موجود
در ادامه مجددا به تمام فایل‌های csproj خود مراجعه کرده و ویژگی Version را از آن‌ها حذف کنید؛ مانند:
از این پس دیگر هیچکدام از فایل‌های پروژه‌ی شما نباید به همراه قید صریح شماره نگارش بسته‌های مورد استفاده باشند؛ در غیر اینصورت در حین Build پروژه، خطای زیر را دریافت خواهید کرد:
همچنین اگر دقت کرده باشید، ویژگی جدید ManagePackageVersionsCentrally نیز به این فایل پروژه و سایر فایل‌های پروژه نیز باید اضافه شود. حالت پیش‌فرض آن false است.
یک نکته: می‌توان ویژگی ManagePackageVersionsCentrally را نیز به صورت سراسری به فایل Directory.Packages.props اضافه کرد تا به صورت خودکار به تمام فایل‌های csproj موجود، اعمال شود:
نحوه‌ی افزودن بسته‌های جدید
قابلیتی که تا اینجا معرفی شد، در NET Core SDK 3.1.300. به بعد قابل دسترسی و استفاده‌است (و پس از این تغییرات، برنامه بدون مشکل کامپایل می‌شود)؛ اما هنوز NET Core CLI. برای افزودن خودکار بسته‌های جدید NuGet به این سیستم، به روز رسانی نشده‌است. یعنی فعلا اگر خواستید بسته‌ی جدیدی را اضافه کنید باید ابتدا به صورت دستی PackageVersion آن‌را در فایل Directory.Packages.props ثبت کنید و سپس PackageReference بدون شماره‌ی نگارش را نیز به پروژه‌ی مدنظر خود به صورت دستی اضافه کنید.
برای مطالعه بیشتر
مستندات رسمی آن
وضعیت پیاده سازی آن
ایجاد فایل جدید Directory.Packages.props
زمانیکه قرار است شماره نگارش‌های بسته‌های NuGet مختلف مورد استفاده‌ی در برنامه، به صورت مرکزی مدیریت شوند، نیاز به یک مخزن ثبت آن‌ها نیز می‌باشد. به همین جهت یک فایل جدید را به نام Directory.Packages.props در کنار فایل sln پروژه‌ی خود ایجاد کنید (در ریشه‌ی اصلی پروژه)؛ با این محتوای فرضی:
<Project>
<ItemGroup>
<PackageVersion Include="Microsoft.Extensions.Localization.Abstractions" Version="3.1.8" />
<PackageVersion Include="Microsoft.Extensions.Logging.Abstractions" Version="3.1.8" />
</ItemGroup>
</Project> تغییرات مورد نیاز در فایل‌های پروژه‌های موجود
در ادامه مجددا به تمام فایل‌های csproj خود مراجعه کرده و ویژگی Version را از آن‌ها حذف کنید؛ مانند:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netcoreapp3.1</TargetFramework>
<ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.Extensions.Localization.Abstractions" />
<PackageReference Include="Microsoft.Extensions.Logging.Abstractions" />
</ItemGroup>
</Project> error NU1008: Projects that use central package version management should not define the version on the PackageReference items
همچنین اگر دقت کرده باشید، ویژگی جدید ManagePackageVersionsCentrally نیز به این فایل پروژه و سایر فایل‌های پروژه نیز باید اضافه شود. حالت پیش‌فرض آن false است.
یک نکته: می‌توان ویژگی ManagePackageVersionsCentrally را نیز به صورت سراسری به فایل Directory.Packages.props اضافه کرد تا به صورت خودکار به تمام فایل‌های csproj موجود، اعمال شود:
<Project>
<PropertyGroup>
<ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
</PropertyGroup>
<ItemGroup>
<PackageVersion Include="Microsoft.Extensions.Localization.Abstractions" Version="3.1.8" />
<PackageVersion Include="Microsoft.Extensions.Logging.Abstractions" Version="3.1.8" />
</ItemGroup>
</Project> نحوه‌ی افزودن بسته‌های جدید
قابلیتی که تا اینجا معرفی شد، در NET Core SDK 3.1.300. به بعد قابل دسترسی و استفاده‌است (و پس از این تغییرات، برنامه بدون مشکل کامپایل می‌شود)؛ اما هنوز NET Core CLI. برای افزودن خودکار بسته‌های جدید NuGet به این سیستم، به روز رسانی نشده‌است. یعنی فعلا اگر خواستید بسته‌ی جدیدی را اضافه کنید باید ابتدا به صورت دستی PackageVersion آن‌را در فایل Directory.Packages.props ثبت کنید و سپس PackageReference بدون شماره‌ی نگارش را نیز به پروژه‌ی مدنظر خود به صورت دستی اضافه کنید.
برای مطالعه بیشتر
مستندات رسمی آن
وضعیت پیاده سازی آن