مطالب
استفاده از افزونه‌های Owin مخصوص سایر نگارش‌های ASP.NET در ASP.NET Core
همانطور که اطلاع دارید یکسری از کتابخانه‌های کمکی و ثالث ASP.NET Core همچون OData و SignalR ، Thinktecture IdentityServer هنوز در حال تکمیل هستند و از آنجایی که هر روزه محبوبیت ASP.NET Core در بین برنامه نویسان در حال افزایش است و خیلی از پروژه‌های نرم افزاری که امروزه start میخورند، از این فریم ورک جدید استفاده میکنند، پس خیلی به اهمیت این مقوله افزوده میشود که بتوان از تکنولوژی‌های فوق در پروژه‌های جدید نیز استفاده کرد و یکی از معقول‌ترین راه‌های ممکن آن، پیاده سازی Owin  در کنار ASP.NET Core Pipeline میباشد. بدین معنا که ما قصد نداریم owin pipeline را جایگزین آن نماییم؛ همانطور که در ادامه‌ی این مقاله گفته خواهد شد، از هر دو معماری (افزونه‌های Owin مخصوص نگارش کامل دات نت و همچنین خود ASP.NET Core) در کنار هم استفاده خواهیم کرد.
پیشنیاز این مقاله آشنایی با ASP.NET Core و MiddleWare و همچنین آشنایی با Owin میباشد. همانطور که عرض کردم اگر مقاله‌ی پیاده سازی OData را مطالعه کرد‌ه‌اید و هم اکنون قصد و یا علاقه‌ی به استفاده‌ی از آن را در پروژه‌ی ASP.NET Core خود دارید، میتوانید این مقاله را دنبال نمایید.
پس تا کنون متوجه شدیم که هدف از این کار، توانایی استفاده از ابزارهایی است که با Owin سازگاری کامل را دارند و همچنین به نسخه‌ی پایدار خود رسیده‌اند. بطور مثال IdentityServer 4 در حال تهیه است که با ASP.NET Core سازگار است. اما هنوز چند نسخه‌ی beta از آن بیرون آمده و به پایداری کامل نرسیده است. همچنین زمان توزیع نهایی آن نیز دقیقا مشخص نیست.
شما برای استفاده از ASP.NET Core RTM 1.0 احتیاج به Visual studio 2015 update 3 دارید. ابتدا یک پروژه‌ی #C از نوع Asp.Net Core Web Application  را «به همراه full .Net Framework» به نام OwinCore میسازیم.
در حال حاضر بدلیل اینکه پکیج‌هایی مانند OData, SignalR هنوز به نسخه‌ی Net Coreی خود آماده نشده‌اند (در حال پیاده سازی هستند)، پس مجبور به استفاده از full .Net framework هستیم و خوب مسلما برنامه در این حالت چند سکویی نخواهد بود. اما به محض اینکه آن‌ها آماده شدند، میتوان full .Net را کنار گذاشته و از NET Core. استفاده نمود و از آنجایی که Owin فقط یک استاندارد هست، هیچ مشکلی با NET Core. نداشته و برنامه را میتوان بدان منتقل کرد و از مزایای چند سکویی بودن آن نیز بهره برد. پس مشکل در حال حاضر Owin نبوده و مجبور به منتظر بودن برای آماده شدن این پکیج‌ها خواهیم بود. مثال عملی این قضیه نیز Nancy است که نسخه‌ی NET Core.ی آن با استفاده از Owin در ASP.NET Core پیاده سازی شده است. در اینجا مثال عملی آن را میتوانید پیدا کنید.


در قسمت بعد، قالب را هم از نوع empty انتخاب مینماییم.


در ادامه فایل project.json را باز کرده و در قسمت dependencies، تغییرات زیر را اعمال نمایید.

قبل از اینکه شما را از این همه وابستگی نگران کنم، باید عرض کنم فقط Microsoft.Owin , Microsoft.AspNetCore.Owin، پکیج‌های اجباری هستند؛ باقی آن‌ها برای نشان دادن انعطاف پذیری بالای این روش میباشند:

"dependencies": {
    "Microsoft.AspNet.OData": "5.9.1",
    "Microsoft.AspNet.SignalR": "2.2.1",
    "Microsoft.AspNet.WebApi.Client": "5.2.3",
    "Microsoft.AspNet.WebApi.Core": "5.2.3",
    "Microsoft.AspNet.WebApi.Owin": "5.2.3",
    "Microsoft.AspNetCore.Diagnostics": "1.0.0",
    "Microsoft.AspNetCore.Hosting": "1.0.0",
    "Microsoft.AspNetCore.Mvc": "1.0.0",
    "Microsoft.AspNetCore.Owin": "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.Net.Http": "2.2.29",
    "Microsoft.Owin": "3.0.1",
    "Microsoft.Owin.Diagnostics": "3.0.1",
    "Microsoft.Owin.FileSystems": "3.0.1",
    "Microsoft.Owin.StaticFiles": "3.0.1",
    "Newtonsoft.Json": "9.0.1"
  },
//etc...

بعد از ذخیره کردن این فایل، در پنجره‌ی Output خود شاهد دانلود شدن این پکیج‌ها خواهید بود. در اینجا پکیج‌های مربوط به Owin, Odata, SignalR را مشاهد می‌کنید. ضمن اینکه در کنار آن، AspNetCore.Mvc را نیز مشاهده میفرمایید. دلیل این کار این است که این دو نوع متفاوت قرار است در کنار هم کار کنند و هیچ مشکلی با دیگری ندارند.

در مسیر اصلی پروژه‌ی خود کلاسی به نام OwinExtensions را با محتوای زیر بسازید:

namespace OwinCore
{
    public static class OwinExtensions
    {
        public static IApplicationBuilder UseOwinApp(
            this IApplicationBuilder aspNetCoreApp,
            Action<IAppBuilder> configuration)
        {
            return aspNetCoreApp.UseOwin(setup => setup(next =>
            {
                AppBuilder owinAppBuilder = new AppBuilder();

                IApplicationLifetime aspNetCoreLifetime = (IApplicationLifetime)aspNetCoreApp.ApplicationServices.GetService(typeof(IApplicationLifetime));

                AppProperties owinAppProperties = new AppProperties(owinAppBuilder.Properties);

                owinAppProperties.OnAppDisposing = aspNetCoreLifetime?.ApplicationStopping ?? CancellationToken.None;

                owinAppProperties.DefaultApp = next;

                configuration(owinAppBuilder);

                return owinAppBuilder.Build<Func<IDictionary<string, object>, Task>>();
            }));
        }
    }
}

یک Extension Method به نام UseOwinApp اضافه شده به IApplicationBuilder که مربوط به ASP.NET Core میباشد و درون آن نیز AppBuilder را که مربوط به Owin pipeline میباشد، نمونه سازی کرده‌ایم که باعث میشود Owin pipeline بر روی ASP.NET Core pipeline سوار شود.

حال میخواهیم یک Middleware سفارشی را با استفاده از Owin نوشته و در Startup پروژه، آن را فراخوانی نماییم. کلاسی به نام AddSampleHeaderToResponseHeadersOwinMiddleware را با محتوای زیر تولید مینماییم:

namespace OwinCore
{
    public class AddSampleHeaderToResponseHeadersOwinMiddleware : OwinMiddleware
    {
        public AddSampleHeaderToResponseHeadersOwinMiddleware(OwinMiddleware next)
            : base(next)
        {
        }
        public async override Task Invoke(IOwinContext context)
        {
            //throw new InvalidOperationException("ErrorTest");

            context.Response.Headers.Add("Test", new[] { context.Request.Uri.ToString() });

            await Next.Invoke(context);
        }
    }
}

کلاسی است که از owinMiddleware ارث بری کرده و در متد override شده‌ی Invoke نیز با استفاده از IOwinContext، به پیاده سازی Middleware خود میپردازیم. Exception مربوطه را comment کرده (بعدا در مرحله‌ی تست از آن نیز استفاده مینماییم) و در خط بعدی در هدر response هر request، یک شیء را به نام Test و با مقدار Uri آن request، میسازیم.

خط بعدی هم اعلام میدارد که به Middleware بعدی برود.

در ادامه فایل Startup.cs را باز کرده و اینگونه متد Configure را تغییر دهید:

public void Configure(IApplicationBuilder aspNetCoreApp, IHostingEnvironment env)
        {
            aspNetCoreApp.UseOwinApp(owinApp =>
            {
                if (env.IsDevelopment())
                {
                    owinApp.UseErrorPage(new ErrorPageOptions()
                    {
                        ShowCookies = true,
                        ShowEnvironment = true,
                        ShowExceptionDetails = true,
                        ShowHeaders = true,
                        ShowQuery = true,
                        ShowSourceCode = true
                    });
                }

                owinApp.Use<AddSampleHeaderToResponseHeadersOwinMiddleware>();
            });
        }

مشاهده میفرمایید با استفاده از UserOwinApp میتوانیم Middleware‌های Owinی خود را register نماییم و نکته‌ی قابل توجه این است که در کنار آن نیز می‌توانیم از IHostingEnviroment مربوط به ASP.NET core استفاده نماییم. owinApp.UseErrorPage از Microsoft.Owin.Diagnostics گرفته شده است و در خط بعدی نیز Middleware شخصی خود را register کرده‌ایم. پروژه را run کرده و در response این را مشاهد مینمایید.

اکنون اگر در Middleware سفارشی خود، آن Exception را از حالت comment در بیاوریم، در صورتیکه در حالت development باشیم، با این صفحه مواجه خواهیم شد:

Exception مربوطه را به حالت comment گذاشته و ادامه میدهیم.

برای اینکه نشان دهیم Owin و ASP.NET Core pipeline در کنار هم میتوانند کار کنند، یک Middleware را از نوع ASP.NET Core نوشته و آن را register مینماییم. کلاسی جدیدی را به نام AddSampleHeaderToResponseHeadersAspNetCoreMiddlware با محتوای زیر میسازیم:

namespace OwinCore
{
    public class AddSampleHeaderToResponseHeadersAspNetCoreMiddlware
    {
        private readonly RequestDelegate Next;

        public AddSampleHeaderToResponseHeadersAspNetCoreMiddlware(RequestDelegate next)
        {
            Next = next;
        }

        public async Task Invoke(HttpContext context)
        {
            //throw new InvalidOperationException("ErrorTest");

            context.Response.Headers.Add("Test2", new[] { "some text" });

            await Next.Invoke(context);
        }
    }
}

متد Configure در Startup.cs را نیز اینگونه تغییر میدهیم

public void Configure(IApplicationBuilder aspNetCoreApp, IHostingEnvironment env)
        {
            aspNetCoreApp.UseOwinApp(owinApp =>
            {
                if (env.IsDevelopment())
                {
                    owinApp.UseErrorPage(new ErrorPageOptions()
                    {
                        ShowCookies = true,
                        ShowEnvironment = true,
                        ShowExceptionDetails = true,
                        ShowHeaders = true,
                        ShowQuery = true,
                        ShowSourceCode = true
                    });
                }

                owinApp.Use<AddSampleHeaderToResponseHeadersOwinMiddleware>();
            });

            aspNetCoreApp.UseMiddleware<AddSampleHeaderToResponseHeadersAspNetCoreMiddlware>();
        }

اکنون AddSampleHeaderToResponseHeadersAspNetCoreMiddlware رجیستر شده است و بعد از run کردن پروژه و بررسی header response باید این را ببینیم

میبینید که به ترتیب اجرای Middleware‌ها، ابتدا Test مربوط به Owin و بعد آن Test2 مربوط به ASP.NET Core تولید شده است.

حال اجازه دهید Odata را با استفاده از Owin پیاده سازی نماییم. ابتدا کلاسی را به نام Product با محتوای زیر تولید نمایید:

namespace OwinCore
{
    public class Product
    {
        public int Id { get; set; }
        public string Name { get; set; }
        public decimal Price { get; set; }
    }
}

حال کلاسی را به نام ProductsController با محتوای زیر میسازیم:

namespace OwinCore
{
    public class ProductsController : ODataController
    {
        [EnableQuery]
        public IQueryable<Product> Get()
        {
            return new List<Product>
            {
                 new Product { Id = 1, Name = "Test" , Price = 10 }
            }
            .AsQueryable();
        }
    }
}

اگر مقاله‌ی پیاده سازی Crud با استفاده از OData را مطالعه کرده باشید، قاعدتا با این کد‌ها آشنا خواهید بود. ضمن اینکه پرواضح است که OData هیچ وابستگی به entity framework ندارد.

برای config آن نیز در Startup.cs پروژه و متد Configure، تغییرات زیر را اعمال مینماییم.

public void Configure(IApplicationBuilder aspNetCoreApp, IHostingEnvironment env)
        {
            //aspNetCoreApp.UseMvc();

            aspNetCoreApp.UseOwinApp(owinApp =>
            {
                if (env.IsDevelopment())
                {
                    owinApp.UseErrorPage(new ErrorPageOptions()
                    {
                        ShowCookies = true,
                        ShowEnvironment = true,
                        ShowExceptionDetails = true,
                        ShowHeaders = true,
                        ShowQuery = true,
                        ShowSourceCode = true
                    });
                }
                // owinApp.UseFileServer(); as like as asp.net core static files middleware
                // owinApp.UseStaticFiles(); as like as asp.net core static files middleware
                // owinApp.UseWebApi(); asp.net web api / odata / web hooks

                HttpConfiguration webApiConfig = new HttpConfiguration();
                ODataModelBuilder odataMetadataBuilder = new ODataConventionModelBuilder();
                odataMetadataBuilder.EntitySet<Product>("Products");
                webApiConfig.MapODataServiceRoute(
                    routeName: "ODataRoute",
                    routePrefix: "odata",
                    model: odataMetadataBuilder.GetEdmModel());
                owinApp.UseWebApi(webApiConfig);

                owinApp.MapSignalR();

                //owinApp.Use<AddSampleHeaderToResponseHeadersOwinMiddleware>();
            });

            //aspNetCoreApp.UseMiddleware<AddSampleHeaderToResponseHeadersAspNetCoreMiddlware>();
        }

برای config مخصوص Odata، به HttpConfiguration نیاز داریم. بنابراین instanceی از آن گرفته و برای مسیریابی Odata از آن استفاده مینماییم.

با استفاده از پیاده سازی که از استاندارد Owin انجام دادیم، مشاهده کردید که Odata را همانند یک پروژه‌ی معمولی asp.netی، config نمودیم. در خط بعدی هم SignalR را مشاهده مینمایید.

اکنون اگر آدرس زیر را در مرورگر خود وارد نمایید، پاسخ زیر را از Odata دریافت خواهید کرد:

http://localhost:YourPort/odata/Products

بعد از فرستادن request فوق، باید response زیر را دریافت نمایید:

{ 
 "@odata.context":"http://localhost:4675/odata/$metadata#Products","value":[
    {
      "Id":1,"Name":"Test","Price":10
    }
  ]
}

تعداد زیادی Owin Middleware موجود همانند Thinktecture IdentityServer, NWebSec, Nancy, Facebook OAuth , ... هم با همان آموزش راه اندازی بر روی Owin که دارند میتوانند در ASP.NET Core نیز استفاده شوند و زمانی که نسخه‌ی ASP.NET Core اینها به آمادگی کامل رسید، با کمترین تغییری میتوان از آنها استفاده نمود.
اگر در پیاده سازی مقاله‌ی فوق با مشکل رو به رو شدید (اگر مراحل به ترتیب اجرا شوند، مشکلی نخواهید داشت) میتوانید از Github ، کل این پروژه را clone کرده و همچنین طبق commit‌های منظم از طریق history آن، مراحل جلو رفتن پروژه را دنبال نمایید.
مطالب
توسعه برنامه‌های Cross Platform با Xamarin Forms & Bit Framework - قسمت نهم
در قسمت‌های قبل یاد گرفتید که چطور View و View Model را در متد RegisterTypes در App.xaml.cs به یکدیگر وصل کرده و به آن‌ها یک اسم دهید و با Navigation Service آن‌ها را در حالت‌های مختلف مثل Navigation Page و Master Detail و Popup و ... باز کنید و بین صفحات جابجا شوید.
در View‌ها دو مورد را به صورت ابتدایی توضیح دادیم، Binding و Command. در این قسمت وارد جزئیات می‌شویم.

Command قطعه‌ای کد در View Model است (عموما یک متد CSharp ای) که در View می‌تواند مورد استفاده قرار گیرد. برای این که کلیک بر روی یک دکمه، متد مربوطه در View Model را اجرا کند، آن را درون یک BitDelegateCommand قرار دادیم و به Command دکمه Bind کردیم.
می‌دانیم که Button، بجز کلیک، دارای Event‌های دیگری نیز هست. علاوه بر این، ممکن است بجای کلیک دکمه، بخواهیم زمانیکه روی یک عکس عمل Swipe انجام می‌شود، کاری در سمت View Model انجام شود.
برای حل این مشکل از Event To Command و Gesture Recognizer استفاده می‌کنیم. مورد اول همانطور که از نام‌اش پیداست، وظیفه آن اتصال بر قرار کردن بین یک Event و یک Command است و دومی نیز برای مسائلی چون Swipe - Tap - Pan - Pinch و ... بکار می‌رود.
در کد پایین که می‌تواند در HelloWorldView.xaml در پروژه XamApp نیز تست شود، یکبار Command دکمه را Bind کرده‌ایم و یکبار Clicked Event آن را، که البته نتیجه یکی است! به جای نام Clicked می‌توان نام هر یک از Event‌‌ها را نوشت. همچنین این کار بجز Button، بر روی باقی کنترل‌ها نیز کار می‌کند.
        <Button Command="{Binding IncreaseStepsCountCommand}" Text="Button with command binding" />
        <Button Text="Button with event to command">
            <Button.Behaviors>
                <prismBehaviors:EventToCommandBehavior Command="{Binding IncreaseStepsCountCommand}" EventName="Clicked" />
            </Button.Behaviors>
        </Button>
همانطور که می‌بینید، EventToCommandBehavior که توسط Prism ارائه شده‌است، به Behavior‌های Button اضافه شده‌است. هر Behavior، رفتاری خاص را به کنترل‌های شما اضافه می‌کند و امکان نوشتن Custom behavior نیز وجود دارد که از موضوع این بحث خارج است.

prismBehaviors در بالای فایل Xaml به شکل زیر تعریف شده است:
xmlns:prismBehaviors="clr-namespace:Prism.Behaviors;assembly=Prism.Forms"
این عمل معادل using نوشتن در بالای فایل‌های CSharp است و می‌گوید که EventToCommandBehavior در کدام namespace و dll است. وقتی این کار را می‌کنید، می‌توانید در Xaml به تمامی کلاس‌های آن namespace دسترسی داشته باشید.

در همان مثال HelloWorldView.xaml، یک Label بود که تعداد زده شدن دکمه را نشان می‌داد. اگر بخواهیم وقتی روی آن Label به سمت چپ Swipe می‌کنیم نیز Command مربوطه اجرا شود، خواهیم داشت:
        <Label Text="{Binding StepsCount, StringFormat='{}Button tapped {0} times!'}">
            <Label.GestureRecognizers>
                <SwipeGestureRecognizer Command="{Binding IncreaseStepsCountCommand}" Direction="Left" />
            </Label.GestureRecognizers>
        </Label>
در صورتیکه قصد تست بر روی Windows-UWP را دارید و صفحه نمایش لمسی ندارید، مطابق با آموزش قسمت Windows همین سری آموزشی، بر روی Simulator خروجی بگیرید.

در مورد Command، مطالبی چون Command Parameter و Event Args Parameter Path و Event Args Converter باقی می‌مانند که در قسمت‌های بعدی به آن‌ها نیز خواهیم پرداخت. ولی به صورت کلی در نظر داشته باشید که جای منطق برنامه، در سمت View Model است و اگر در سناریویی نمی‌دانستید که چگونه در واکنش به تغییری در View، در سمت View Model کاری کنید، می‌توانید همینجا سوال خود را بپرسید.

Binding نیز همان طور که تا الان متوجه شده‌اید، باعث اتصال دو چیز به یک دیگر می‌شود. وقتی می‌نویسیم:
<Label Text="{Binding StepsCount, StringFormat='{}Button tapped {0} times!'}" />
داریم Text را که یک Property در Label در View است، به StepsCount که یک Property در View Model است، وصل می‌کنیم.
هر Binding یک Source دارد. به صورت پیش فرض، چون داریم از Prism استفاده می‌کنیم، تمامی Binding‌ها در View به صورت پیش فرض به View Model اشاره می‌کنند؛ مگر اینکه چیز دیگری بگوییم. برای مثال، اگر بخواهیم یک Label داشته باشیم که متن یک Entry را نمایش می‌دهد، هیچ‌یک از این دو در View Model نیستند. پس در این Binding خاص، باید سورس را نیز مشخص کنیم:
        <Entry x:Name="MyEntry" />
        <Label Text="{Binding Text, Source={x:Reference MyEntry}}" />
این باعث می‌شود که Text، که یک Property در Label است، به Text، که یک Property در کنترلی با نام MyEntry است، وصل شود.

x:DataType
Binding‌ها به صورت پیش فرض، در زمان اجرا و با کمک Reflection کار می‌کنند؛ این مهم دو مسئله را ایجاد می‌کند:
1- اگر در View، نام Property مد نظر در View Model را به اشتباه بنویسید، تا زمانیکه برنامه را اجرا نکنید و وارد آن فرم نشوید، متوجه مشکل دار بودن ماجرا نمی‌شوید و وقتی در View Model نام یک Property را عوض می‌کنید، در سمت View در هنگام Build خطایی نمی‌گیرید.
2- Reflection چیز خوبی است و برخی سناریوها بدون آن خیلی سخت پیاده سازی می‌شوند؛ ولی Reflection سربار کارآیی دارد و بهتر است در صورت امکان از آن پرهیز شود.
برای حل این مشکل در Xamarin Forms امکانی به نام x:DataType معرفی شده‌است که در View می‌گویید که Source چه کلاسی است، که قاعدتا View Model است. برای این کار داریم:
<ContentPage
...
    xmlns:vm="clr-namespace:XamApp.ViewModels"
    x:DataType="vm:HelloWorldViewModel">
با این روش، هر دو مشکل فوق حل می‌شوند و هم خطای زمان Build برای Binding‌های اشتباه خواهیم داشت و هم بدون Reflection از Binding‌ها استفاده می‌کنیم که بهبود سرعت برنامه را در بر دارد.

INotifyPropertyChanged
در مثال XamApp، وقتی روی دکمه کلیک می‌کنیم، مقدار StepsCount را که یک Property در View Model است، یکی یکی افزایش می‌دهیم. این Property در View به Label بایند شده‌است. وقتی مقداری در View Model که سورس Binding ما محسوب می‌شود رخ می‌دهد، View چگونه خبر دار می‌شود؟
هر کلاسی که بخواهد در Binding به عنوان Source استفاده شود (منجمله View Model)، می‌تواند یک interface را پیاده سازی کند؛ به نام INotifyPropertyChanged. همچنین تعریف یک Property نیز باید به این شکل باشد:
        private int _StepsCount;
        public int StepsCount
        {
            get => _StepsCount;
            set => SetProperty(ref _StepsCount, value);
        }
طبیعتا این کد که در سناریوهایی می‌تواند حتی پیچیده‌تر شود، جالب نیست و برای همین ما از  PropertyChanged.Fody استفاده کرده‌ایم که در زمان Build، خودش همه مسائل را مدیریت می‌کند و کد فوق به سادگی می‌تواند به صورت زیر نوشته شود:
public int StepsCount { get; set; }
به صفحه GitHub این کتابخانه مراجعه کنید و با سایر امکانات فوق العاده‌ی آن آشنا شوید!
در Binding، موارد دیگری چون Value Converters و Relative Source نیز وجود دارند که در ادامه با آنها آشنا می‌شویم. اگر در Binding نیز مشکلی دارید، می‌توانید همینجا نیز بپرسید.
مسیرراه‌ها
ASP.NET MVC
              مطالب
              چگونه از دو نگارش مختلف یک اسمبلی در برنامه‌های NET Core. استفاده کنیم؟
              فرض کنید اسمبلی A که System.Drawing.Common، نام دارد، فضای نام System.Drawing.Common را ارائه می‌دهد و اسمبلی B که CoreCompact.System.Drawing نام دارد، باز هم دقیقا همان فضای نام را ارائه می‌دهد. سؤال: آیا می‌توان از این دو اسمبلی مختلف در برنامه‌ی خود استفاده کرد؟ یا مثال دیگر آن داشتن دو اسمبلی با نگارش‌های مختلف، از یک کتابخانه است. برای مثال یکی بر اساس netcoreapp2.1 تهیه شده‌است و دیگری بر اساس netstandard2.0 و به هر دلیلی نیاز است که بتوان از هر دو اسمبلی در برنامه‌ی خود استفاده کرد. برای یک چنین مواردی در زبان #C ویژگی به نام extern alias وجود دارد که با مثالی نحوه‌ی کار با آن‌را بررسی خواهیم کرد.


              ایجاد پروژه‌ی Globe1

              پروژه‌ی کتابخانه‌ی Globe1 را بر اساس netcoreapp2.1 به این صورت توسط فایل‌های زیر ایجاد می‌کنیم:

              الف) فایل Globe1.csproj
              <Project Sdk="Microsoft.NET.Sdk">
                  <PropertyGroup>
                      <TargetFramework>netcoreapp2.1</TargetFramework>
                  </PropertyGroup>
              </Project>

              ب) فایل Globe.cs
              using System;
              
              namespace Space
              {
                  public class Globe
                  {
                      public string GetColor() => "Blue";
                  }
              }


              ایجاد پروژه‌ی Globe2

              پروژه‌ی کتابخانه‌ی Globe2 را بر اساس netstandard2.0 به این صورت توسط فایل‌های زیر ایجاد می‌کنیم:

              الف) فایل Globe2.csproj
              <Project Sdk="Microsoft.NET.Sdk">
                  <PropertyGroup>
                      <TargetFramework>netstandard2.0</TargetFramework>
                  </PropertyGroup>
              </Project>

              ب) فایل Globe.cs
              using System;
              
              namespace Space
              {
                  public class Globe
                  {
                      public string GetColor() => "Green";
                  }
              }


              ایجاد یک پروژه‌ی کنسول استفاده کننده‌ی از این اسمبلی‌ها

              همانطور که ملاحظه می‌کنید اگر این دو پروژه‌ی class library را کامپایل کنیم، به دو فایل dll یا اسمبلی خواهیم رسید که هر دو دارای فضای نام Space و همچنین کلاس Globe هستند. اما نگارش‌های آن‌ها و یا TargetFrameworkهای آن‌ها متفاوت است. اکنون می‌خواهیم از هر دوی این‌ها در یک پروژه‌ی Console استفاده کنیم. بنابراین ابتدا این پروژه را با ایجاد فایل csproj آن شروع می‌کنیم:

              الف) فایل Owl.csproj
              <Project Sdk="Microsoft.NET.Sdk">
                  <PropertyGroup>
                      <OutputType>Exe</OutputType>
                      <TargetFramework>netcoreapp2.1</TargetFramework>
                  </PropertyGroup>
                  <ItemGroup>
                      <Reference Include="Globe1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null">
                          <HintPath>..\Globe1\bin\$(Configuration)\netcoreapp2.1\Globe1.dll</HintPath>
                          <Aliases>Lib1</Aliases>
                      </Reference>
              
                      <Reference Include="Globe2, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null">
                          <HintPath>..\Globe2\bin\$(Configuration)\netstandard2.0\Globe2.dll</HintPath>
                          <Aliases>Lib2</Aliases>
                      </Reference>
                  </ItemGroup>
              </Project>
              روش ارجاع دهی به این اسمبلی‌ها، اندکی متفاوت است. در اینجا نام هر کدام به همراه شماره نگارش آن‌ها ذکر شده‌است. همچنین مسیر یافتن فایل‌های Globe1.dll و Globe2.dll نیز ذکر شده‌اند؛ بجای اینکه ارجاعی را به فایل‌های csproj این class libraryها اضافه کنیم (از این جهت که ممکن است مانند مثال ابتدای بحث، صرفا دو فایل dll را بیشتر در اختیار نداشته باشیم). به علاوه یک Alias نیز برای هر کدام تعریف شده‌است تا توسط آن بتوان به امکانات هرکدام دسترسی یافت. وجود این Alias از این جهت ضروری است که هرچند دو فایل dll مختلف را داریم، اما فضاهای نام و کلاس‌های آن‌ها، نام‌های مشابهی دارند و قابل تمیز از یکدیگر نیستند.

              ب) فایل Program.cs

              اکنون قسمت مهم این فایل، همان extern aliasهایی هستند که پیشتر تعریف کردیم:
              extern alias Lib1;
              extern alias Lib2;
              using System;
              using SpaceOne = Lib1::Space;
              using SpaceTwo = Lib2::Space;
              
              namespace Owl
              {
                  class Program
                  {
                      static void Main(string[] args)
                      {
                          var owl = new SuperOwl();
                          owl.IntegrateGlobe(new SpaceOne.Globe());
                          owl.IntegrateGlobe(new SpaceTwo.Globe());
              
                          Console.WriteLine(owl.GetGLobeColors());
                      }
                  }
              
                  public class SuperOwl
                  {
                      private SpaceOne.Globe _firstGlobe;
                      private SpaceTwo.Globe _secondGlobe;
              
                      public void IntegrateGlobe(SpaceOne.Globe globe) => _firstGlobe = globe;
                      public void IntegrateGlobe(SpaceTwo.Globe globe) => _secondGlobe = globe;
                      public string GetGLobeColors() => $"First: {_firstGlobe.GetColor()}, Second: {_secondGlobe.GetColor()}";
                  }
              }
              ابتدا extern aliasها تعریف می‌شوند:
              extern alias Lib1;
              extern alias Lib2;
               سپس بر اساس هر Alias می‌توان یک فضای نام جدید را بجای فضای نام Space فعلی هرکدام تعریف کرد:
              using SpaceOne = Lib1::Space;
              using SpaceTwo = Lib2::Space;
               تا بتوان به متدهای GetColor متفاوت این‌ها دسترسی یافت.

              اگر این برنامه را اجرا کنیم، چنین خروجی حاصل می‌شود:
              First: Blue, Second: Green

              کدهای کامل این مثال را از اینجا می‌توانید دریافت کنید: alias.zip
              اشتراک‌ها
              دانلود تمامی محتوای کنفرانس Microsoft Build 2017
              در هفته‌ی گذشته کنفرانس Microsoft Build 2017 برگزار و جدیدترین تکنولوژی‌های مرتبط با حوزه‌های کاربری و توسعه در آن مطرح گردید. با استفاده از فایل PowerShell ذیل می‌توانید تمامی محتوای این کنفرانس را با کیفیت بالا دانلود نمایید. ویژگی‌های استفاده از این اسکریپت به شرح ذیل می‌باشد:
              • دانلود تمامی محتواها شامل ویدیوها، اسلایدها و متون ارائه شده
              • گروه بندی در فولدرهای مختلف
              • شروع مجدد دانلود در صورت قطع ارتباط از آخرین مرحله
              • فیلتر نمودن دانلود براساس کلمات کلیدی مورد نظر
              • توانایی انتخاب فرمت ویدیوها جهت دانلود
              جهت استفاده از این اسکریپت مراحل ذیل را دنبال کنید.
              • به آدرس ذیل مراجعه و فایل PowerShell مربوطه را دانلود نمایید.
              • جهت دانلود تمامی محتواهای مطرح شده با حجم حدودی 1 ترابایت از دستور ذیل استفاده نمایید.
              .\ DownloadBuild2017Content.ps1
              • جهت دانلود براساس کلمات کلیدی مورد نظر از دستور ذیل استفاده نمایید. 
              .\ DownloadBuild2017Content.ps1 -keyword "Graph,Bluetooth"
              • جهت دانلود براساس کدهای مرتبط با Session‌های برگزار شده از دستور ذیل استفاده نمایید.
              .\DownloadBuild2017Content.ps1 -session "P4116,P4118,C9R04"
              دقت داشته باشید که تمامی ویدیوها به صورت پیش فرض با فرمت HD دانلود می‌شوند، در صورتی که می‌خواهید فرمت ویدیوها را جهت دانلود سریع‌تر تغییر دهید می‌بایست خطوط 18 و 19 فایل دانلود شده را تغییر دهید.
              دانلود تمامی محتوای کنفرانس Microsoft Build 2017
              مطالب
              راه اندازی سرور Git با استفاده از Bonobo Git Server و انتقال از ساب ورژن به گیت
              تا چندی پیش شاید برای استفاده‌ی از گیت و راه اندازی سرور عملیاتی آن در ویندوز، مشکلاتی مانند سبک راه اندازی آن که لینوکسی و کامندی بود، مانعی برای استفاده بود. ولی با استفاده از Bonobo Git Server که با ASP.NET MVC نوشته شده‌است و بصورت مدفون شده (embedded) از گیت استفاده می‌کند، راه انداختن سرور گیت خیلی آسان و با مراحلی خیلی کمتر و پسندیده‌تر، قابل انجام است. من تا مدتی قبل، برای استفاده‌ی شخصی به مدتی طولانی از Subversion برای نگهداری تاریخچه‌ی پروژه‌ها استفاده و حتی مثالهایی را که می‌نوشتم در این سرور ذخیره می‌کردم. ولی با توجه به سرعت فوق العاده‌ای که گیت داشت و نیز یکپارچگی که با آن در داخل ویژوال استودیو به‌وجود آمده، شاید بد نباشد حتی برای استفاده‌ی شخصی و بصورت تیم تک نفره هم این سورس کنترلر قوی را انتخاب کرد.
              برای این منظور ابتدا آخرین نسخه‌ی  Bonobo Git Server را از آدرس مخرن آن دریافت می‌کنید و با توجه ویندوز، پیشنیاز‌های آن را نصب می‌کنیم:
              - نصب و راه اندازی IIS
              - نصب دات نت فریمورک 4.5
              - نصب ASP.NET MVC نسخه 4.0
              مانند هاست کردن یه برنامه وب ASP.NET محتوای آن را هاست میکنیم:
               همانطور که در تصویر زیر می‌بینید، این برنامه از فولدر App_Data بصورت پیش فرض برای نگهداری گیت و مخازن آن استفاده کرده است :

              این سرور در فایل config.xml قرار گرفته در فولدر App_Data، تنظیمات مربوط به فراخوانی‌هایی را که در داخل برنامه‌ی وب به گیت می‌دهد، ذخیره می‌کند؛ از جمله در آن مشخص می‌شود که فولدر نگهداری مخازن کجا قرار گرفته‌است. من برای استفاده، این آدرس را به درایوی غیر از درایو ویندوز تغییر دادم:
              <?xml version="1.0"?>
              <Configuration xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
                <AllowAnonymousPush>false</AllowAnonymousPush>
                <Repositories>D:\GitRepo</Repositories>
                <AllowUserRepositoryCreation>true</AllowUserRepositoryCreation>
                <AllowAnonymousRegistration>false</AllowAnonymousRegistration>
                <DefaultLanguage>en-US</DefaultLanguage>
                <IsCommitAuthorAvatarVisible>true</IsCommitAuthorAvatarVisible>
              </Configuration>
              و در ادامه باید در این فولدر، به کاربر IIS دسترسی خواندن و نوشتن داد:

              حالا آدرس مربوط به سرور وب آن را در مرورگر وارد می‌کنیم و با کاربر admin و کلمه‌ی عبور admin وارد سیستم می‌شویم.

              قابلیت جالبی که در اینجا به نظر من خیلی مهم بود، استخراج تاریخچه‌ی کامل ساب ورژن توسط گیت و انتقال همه آنها به مخزن گیت است که تنها با یک خط فرمان انجام پذیر است. برای اینکار مخرنی را در گیت ساخته و آدرس .git آن را برای اجرای فرمان نگه می‌داریم:

              البته نصب گیت برای ویندوز برای صدور فرمان انتقال به گیت الزامی است که می‌توانید از این آدرس آن‌را دانلود و نصب کنید.

              پس از آن در 2 مرحله مخرن ساب ورژن را به گیت انتقال می‌دهیم:

              1- استخراج آن در یک مخزن لوکال

              2- افزودن به سرور گیت (که راه اندازی شده)

              برای استخراج مخزنی از ساب ورژن به یک مخزن لوکال گیت، یک فولدر خالی را ایجاد می‌کنیم. سپس با خط فرمان به آن وارد می‌شویم و بعد فرمان زیر را اجرا می‌کنیم:

              در ادامه نام کاربری و کلمه‌ی عبور را وارد می‌کنیم. البته به صورت پیش فرض، نام کاربری جاری ویندوز را در نظر می‌گیرد و بعد نام کاربری و کلمه‌ی عبور سرویس ساب ورژن را می‌پرسد و حالا گیت کارش را شروع میکند:


              پس از اتمام کار با توجه به مقاله‌ی «مراحل ارسال یک پروژه‌ی Visual Studio به GitHub» برای کار با گیت در ویژوال استودیو، می‌توان به کار با گیت بصورت ریموت ادامه دهید.

              و اما نکته‌ی آخر: من برای استفاده از این سرور مجبور بودم که نام localhost را با نام mehdi-pc جابجا کنم تا بتوانم از طریق یک کامپیوتر دیگر با سورس کنترل کار کنم و طی جستجوهایی که در اینترنت کردم، این کار بصورت کامند و فرمان‌های شبه لینوکسی انجام پذیر بود. ولی راهی را همچون این مقاله «مشکل در جابجایی پروژه‌های svn» پیدا کردم که بنظرم آن‌را مرتبط با موضوع می‌دانم و گفتن آن را خالی از لطف نمی‌بینم.

              فایل config در واقع فایل کانفیگ داخل مخزن لوکال است؛ یعنی داخل فولدر .git و بصورت متنی ذخیره شده است:

              طبق انتظار قسمتی از فایل که در زیر آمده، مربوط به مشخصات اتصال به سرور ریموت میباشد:

              [remote "origin"]
              url = http://mehdi-pc:8551/NewsService.git
              fetch = +refs/heads/*:refs/remotes/origin/*

              البته باید بسیار با دقت این تغییر را ایجاد کنید و مطمئن باشید که آدرس را بطور صحیح و به یک مخزن درست گیت تغییر می‌دهید.

              مطالب
              یک سرویس (میکروسرویس) چیست؟ و چگونه آن را مستند کنیم؟ (قسمت اول)
              معماری میکروسرویس (یا به اختصار: میکروسرویس) یک سبک معماری نرم افزار می‌باشد که در آن یک نرم افزار، به مجموعه‌ای از سرویس‌ها خرد می‌شود؛ به نحوی که هر سرویس مسئولیت انجام بخشی از منطق کسب و کار را به عهده داشته باشد.
              این تقسیم بندی مزایای متعددی را به همراه دارد که نهایتا پیاده سازی و توسعه راحت‌تر نرم افزار‌های بزرگ و پیچیده را ممکن می‌نماید. از جمله مزایای این معماری می‌توان به راحت‌تر شدن مباحث continuous delivery/deployment، مقیاس پذیری بهتر، تحمل خطا، مهاجرت به (و یا استفاده از) تکنولوژی‌های جدید در بخش‌های مختلف نرم افزار و ... اشاره نمود.

              مهم‌ترین بخش و تصمیمات شما به عنوان یک معمار نرم افزار، هنگام طراحی با استفاده از این معماری، شناسایی بخش‌های مختلف کسب و کار، جدا سازی و مرزبندی نمودن آنها و نهایتا طراحی سرویس‌ها و تعیین نحوه همکاری آنها با یکدیگر می‌باشد. لذا در هنگام استفاده از معماری میکروسرویس، مرکز توجهات باید کسب و کار باشد و نه مسائل تکنیکال و موضوعاتی مانند Docker, Kubernetes , Serverless و ... . (DDD می‌تواند به شما جهت مرزبندی بخش‌های مختلف کسب و کار و شناسایی سرویس‌ها کمک نماید)

              تا اینجا متوجه شدیم که میکروسرویس در واقع یک سبک معماری نرم افزار محسوب می‌گردد و در واقع میکروسرویس (در اینجا و ادامه مقاله، منظور از میکروسرویس، معماری میکروسرویس می‌باشد) از چندین سرویس مجزا و مستقل تشکیل شده‌است که هر سرویس معمولا مسئولیت بخشی از منطق کسب و کار را بر عهده خواهد داشت.

              مشخصات یک سرویس
              هر سرویس در معماری میکروسرویس دارای چندین ویژگی اصلی به شرح زیر می‌باشد:
              - Loosely coupled with other services - باید به طور مستقل از سایر سرویس‌ها عمل کند. به این معنا که تغییر و توسعه سایر سرویس‌ها موجب اختلالی در عملکرد این سرویس نگردد و برعکس، تغییر و توسعه این سرویس نباید عملکرد سایر سرویس‌ها را مختل نماید.
              - Independently deployable - تیم توسعه دهنده سرویس قادر باشد تا بدون نیاز به هماهنگی با سایر تیم‌ها، خدمات خود (شامل ویژگی‌های جدید و تغییرات) را مستقر (Deploy) نماید.
              - Capable of being developed by a small team – سرویس، امکان توسعه توسط یک تیم کوچک را داشته باشد. این مورد به جهت جلوگیری از سربار زیاد ناشی از هماهنگی در تیم‌های بزرگ، ضرورت دارد.
              - Highly maintainable and testable – سرویس بسیار قابل نگهداری و قابل آزمایش باشد؛ امکان توسعه، تست و استقرار سریع را داشته باشد.

              ساختار یک سرویس
              حال که با ویژگی‌ها و مشخصات اصلی یک سرویس آشنا شدیم، در دیاگرام زیر، ساختار درونی یک سرویس را که از معماری هگزاگون (hexagonal architecture) استفاده می‌نماید، بررسی میکنیم. در این معماری، هسته سرویس، منطق کسب کار (Business logic) می‌باشد که توسط چندین آداپتور (جهت ارتباط با سایر سرویس‌ها) احاطه شده است.

              بیایید با دقت به هر یک از بخش‌های یک سرویس (با توجه به دیاگرام فوق) نگاه کنیم

              هر سرویس  احتمالا دارای یک یا چندین API می‌باشد
              از دید مصرف کنندگان یک سرویس (Consumers)، تنها مورد با اهمیت یک سرویس، APIهای آن سرویس می‌باشد. APIهای یک سرویس نیز (با توجه به تصویر فوق) شامل عملیات یا Operations و وقایع منتشر شده یا Published events می‌باشند. که در ادامه این انواع را بررسی میکنیم.

              - عملیات (Operations)
              به صورت کلی و همانطور که در دیاگرام فوق قابل مشاهده می‌باشد، عملیات به دو نوع دستورات (Commands) و جستارها (Queries) تقسیم می‌شوند. دستورات نوعی از عملیات می‌باشند که موجب تغییر داده‌ها می‌شود؛ اما در مقابل جستارها، عملیاتی در جهت واکشی داده‌ها می‌باشند. برای مثال یک سرویس  ثبت سفارش (OrderService) را در نظر بگیرید. عملیاتی مانند ثبت سفارش ()CreateOrder، انصراف از سفارش ثبت شده  ()CancelOrder و ... عملیاتی از نوع دستورات هستند و عملیاتی مانند یافتن یک سفارش خاص ()FindOrder که هیچ دیتایی را تغییر نمیدهد، از نوع جستارها می‌باشند.
              عملیات ارائه شده توسط یک سرویس میتواند از ترکیبی از پروتکل‌های همزمان (Synchronous protocols) مانند REST یا gRPC و پروتکل‌های غیر همزمان (Asynchronous protocols) مانند messaging باشند.
              پروتکل‌های همزمان، به ویژه REST، بیشتر در مواردی که قصد ارائه API به کلاینت‌های خارجی (External clients) را داریم، مانند موبایل اپلیکیشن‌ها و یا نرم افزارهای تک صفحه‌ای (SPA) کاربرد دارند.
              از پروتکل‌های غیر همزمان مانند messaging نیز بیشتر در مواردی که میخواهیم الگوی ساگا (SAGA) را پیاده سازی نماییم و به روز نگه داشتن داده‌ها را بین سرویس‌های مختلف حفظ کنیم، نیاز به استفاده داریم. برای مثال در همان سیستم ثبت سفارش، عملیات ()CreateOrder به صورت Rest و با متد Post در Endpoint ای مانند /Order پیاده سازی می‌شود و پس از فراخوانی، یک عملیات غیرهمزمان مانند CreateOrderSaga را نیز به صورت messaging آغاز میکند.

              - وقایع (Events)
              سرویس‌ها، اغلب وقایعی (Event) را نیز منتشر میکنند. منظور از وقایع یا events معمولا همان مفهوم domain event درDDD می‌باشد که در همان ادبیات DDD وقایع توسط aggregate‌ها در زمان هایی مانند ایجاد، ویرایش، حذف و یا سایر مفاهیم موجود در منطق کسب و کار منتشر می‌شوند. سرویس نیز معمولا این وقایع را روی یک کانال ارتباطی (message channel) که توسط یک message broker (مانند RabbitMQ, Apache Kafka, ActiveMQ و ...) پیاده سازی شده است، منتشر میکند. و علاقمندان به دریافت این وقایع می‌توانند وقایع را پس از انتشار، بر روی کانال ارتباطی دریافت نمایند.


              منطق کسب و کار (Business Logic)
              منطق کسب و کار، قلب هر سرویس و دلیل وجود آن سرویس می‌باشد که API هایی را در قالب عملیات (Opertaions) پیاده سازی و همچنین مواردی را در قالب وقایع (Events) منتشر می‌نماید. همچنین منطق کسب و کار می‌تواند بنا بر نیاز خود، عملیات مربوط به سایر سرویس‌ها را فراخوانی و یا در کانال‌های ارتباطی (channels) مربوط به وقایع آنها، مشترک (Subscribes) شود و نهایتا داده‌ها را در دیتابیس خود نگهداری نماید.

              نحوه همکاری سرویس‌ها با یکدیگر (Services Collaborations)
              با توجه به مفاهیم فوق، زمانی که صحبت از همکاری (collaborate) بین سرویس‌ها می‌شود، معمولا منظور، ارتباط آنها از طریق APIهای یکدیگر (شامل عملیات و وقایع که پیش‌تر توضیح داده شد) می‌باشد (به جای خواندن و نوشتن مستقیم در دیتابیس‌های مربوط به یکدیگر می‌باشد).
              برای مثال یک سرویس ممکن است عملیات مربوط به ایجاد سفارش ()CreateOrder را از سرویس ثبت سفارش (OrderService) فراخوانی نماید و یا برعکس خود سرویس ثبت سفارش (OrderService) ممکن است بر حسب نیاز منطق کسب و کار خود، عملیات ارائه شده توسط سرویس انبار را فراخوانی نماید.
              همچنین یک سرویس جهت همکاری با دیگر سرویس‌ها میتواند در وقایع منتشر شده (Published events) توسط آنها مشترک (Subscribes) شود. برای مثال سرویس ثبت سفارش احتمالا در وقایع منتشر شده از سوی سرویس رستوران مشترک می‌شود.

              دیتابیس اختصاصی
              معمولا هر سرویس دارای یک یا چند دیتابیس می‌باشد که دیتای اختصاصی مربوط به منطق کسب و کار خود و در مواردی بخشی از دیتای مربوط به سایر سرویس‌ها را در آن‌(ها) نگهداری میکند. برای مثال اطلاعات سفارش‌ها را هم سرویس ثبت سفارش و هم سرویس رستوران، هر دو نگهداری میکنند و عملا این دیتا ابتدا در سرویس رستوران و سپس در سرویس ثبت سفارش، مجددا نگهداری می‌شود و به نوعی دیتای فوق Replicate شده و تکراری می‌باشد. اما به جهت اطمینان از کاهش وابستگی (loose coupling) این تکرار داده‌ها انجام می‌شود. در مجموع استفاده از یک دیتابیس مشترک (منظور table مشترک می‌باشد) بین سرویس‌ها ایده‌ی بدی می‌باشد و سرویس‌ها باید از طریق API‌های یکدیگر باهم همکاری نمایند.

              نتیجه
              در این مقاله عنوان شد که میکروسرویس یک سبک معماری می‌باشد و در این معماری، نرم افزار و منطق کسب و کار، به چندین سرویس مختلف  تقسیم می‌شود. مشخصات کلیدی که هر سرویس باید در این سبک معماری (microservice architecture) داشته باشد و همچنین ساختار درونی هر سرویس بررسی شد.
              در قسمت بعدی این مقاله، در مورد نحوه مستند سازی این سرویس‌ها صحبت می‌شود. چرا که با زیاد شدن تعداد سرویس‌ها، در صورت عدم وجود یک مستندات مناسب (documents)، ارتباط و هماهنگی تیم‌ها با یکدیگر خود موجب سربار خواهد شد.

              منابع
              برگرفته شده از مقاله آقای ریچاردسون (whats-a-service
              نظرات مطالب
              ارتقاء به ASP.NET Core 2.0 - معرفی بسته‌ی Microsoft.AspNetCore.All
              افزونه‌ی #C مخصوص VSCode دقیقا همان روزی که NET Core 2.0. ارائه شد، به روز شده‌است. بنابراین پس از نصب SDK جدید، یکبار VSCode را بسته، به اینترنت متصل شوید، سپس VSCode را باز کنید. در برگه‌ی افزونه‌ها مشاهده خواهید کرد که این افزونه به روز شده‌است و باید صفحه را reload کنید. پس از آن یک فایل #C را هم باز کنید تا کار دریافت دیباگر جدید آن آغاز شود. اینجا است که کار به روز رسانی «دو مرحله‌ای» آن تکمیل می‌شود. پس از آن به ریشه‌ی پروژه وارد شده و دستور dotnet restore را صادر کنید تا وابستگی‌های شناسایی نشده، شناسایی شوند.