زمانی که داتنت در سال 2002 معرفی شد، تنها شامل یک چهارچوب بود. در مدت زمان کوتاهی، Net Compact Framework. معرفی شد که زیرمجموعهای از داتنت بهشمار میرفت و برای دستگاههای کوچکتر و بهویژه ویندوز موبایل مورد استفاده قرار میگرفت. این نسخه فشرده از داتنت پایه کدهای متفاوتی از داتنت داشت و از یک Runtime، یک چهارچوب و یک Application model ساخته شد که در بالای این مؤلفهها قرار میگرفت. در ادامه، عناصر مختلفی همچون Windows Phone ،Silverlight و بهتازگی Windows Store به چهارچوب داتنت اضافه شدند. اما این شیوه قرارگیری مؤلفه در نهایت به ازهم گسیختگی مجموعه منجر شد؛ زیرا پلتفرم داتنت یک موجودیت واحد نیست و مجموعهای از پلتفرمها است که توسط گروههای مختلف و مستقل نگهداری میشود (شکل 1).
شکل 1: مؤلفههای موجود در داتنت
مشکل ازهم گسیختگی چیست؟ اگر قرار باشد فقط از یک سیستم استفاده کنید، هیچ مشکلی وجود ندارد. مجموعهای ازواسطهای برنامهنویسی (API) که برای سیستم شما بهینهسازی میشوند، در ساخت و استفاده از برنامه کاربردی مورد استفاده قرار میگیرند. اما مشکل زمانی ظاهر میشود که برنامه باید روی مجموعهای از سیستمها استفاده شود. اکنون دلیلی برای در دسترس بودن این ایپیآیها دارید و لازم است از روشی استفاده کنید که این دارایی روی همه ماشینهای مقصد کار کند. امروزه داشتن برنامههایی که روی بخش گستردهای از دستگاهها باید اجرا شوند، ضروری است. البته برای بهرهمندی از چنین قابلیتی روشهای غیر مستقیم وجود دارد. اما نکته مهم برای طراحان، طراحی مؤلفههایی است که روی همه دستگاههای داتنت کار کنند.
مشکل دیگر زمانی است که داتنت نیازمند تغییر است. وقتی در چهارچوب داتنت تغییری اعمال میشود، تأثیر خود را روی برنامههایی میگذارد که به آن وابسته هستند. حتی اگر این تغییرات سازگار هم باشند، ممکن است بر روند اجرای درست برنامه تأثیرات نامطلوبی بگذارد. اضافه کردن رابط کاربری، اضافه کردن نمونهای به یک شیوه که قبلاً هیچ انشعابی از آن در یک برنامه وجود نداشته است و تغییر نام نوعها بهصورت داخلی، بهویژه اگر در یک برنامه از متدهای ToString برای ارجاع به آن نوع استفاده شده باشد، مثالهایی از این تغییرات هستند.
NetCore. وارد میشود
مشکلات و عواملی که به تعدادی از آنها اشاره کردیم، گروه طراحی داتنت را به تفکر مجدد و تغییر مدل پلتفرم داتنت انداخت تا حرکت رو به رشدی را تجربه کند. نتایج این بازبینی به خلق NetCore. منجر شد (شکل 2). NetCore. پیادهسازی ماژولاری است که روی بخش گستردهای از محصولات، از مراکز داده گرفته تا دستگاههای لمسی بهصورت منبع باز قابل استفاده است. سیستمعاملهای ویندوز، لینوکس و Mac OS X از NetCore. پشتیبانی میکنند. زمانی که Net Native. در مرحله طراحی قرار داشت، کاملاً مشخص بود که از کتابخانههای کلاس داتنت نمیتواند بهعنوان پایه و اساس استفاده کند. زیرا Net Native. بهطور کامل در چهارچوب یک نرمافزار ادغام میشود و سپس کدهایی را که توسط نرمافزار مورد استفاده قرار نمیگیرد، قبل از آنکه کدهای محلی تولید شود، حذف میکند.
شکل 2: نتیجه بررسی در مدل داتنت و تغییرات صورت گرفته روی آن به ساخت Net Core 2015. منجر شد.
NetCore. انشعابی از چهارچوب داتنت بهشمار میرود که پیادهسازی آن در جهت بهینهسازی عواملی است که پیرامون آن قرار دارند. حتی اگر سناریوهای ASP.Net 5 (توسعه وب سمت سرور) و Net Native. (بر پایه دستگاههای لمسی) کاملاً متفاوت باشند، باز هم توانایی ساخت کتابخانههای یکپارچه وجود دارد (شکل 3). بخش ایپیآیها برای NetCore BCL ، .Net Native. و ASP.Net 5 یکسان است. در پایین BCL یک لایه کوچکتر قرار دارد که بهطور ویژه برای Net runtime. است. همچنین، بهتازگی دو پیادهسازی دیگر نیز اضافه شده است؛ یکی Net Native Runtime. و دیگری CoreCLR (بهتازگی منبع باز شده و در ادامه به آن خواهیم پرداخت) که توسط ASP.Net 5 مورد استفاده قرار میگیرد. هرچند این لایه بهندرت دستخوش تغییر میشود و شامل انواع Int32 ،String و... است. بخش عمده BCL از اسمبلیهای خالص MSIL هستند که میتوانند بهاشتراک گذاشته شوند. به عبارت دیگر، این ایپیآیها نه تنها در ظاهر یکسان هستند، بلکه پیادهسازی یکسانی را نیز بهاشتراک میگذارند. بهطور مثال، هیچ دلیلی وجود ندارد که پیادهسازیهای مختلفی از مجموعهها داشته باشیم.
شکل3: ساختار و لایههای بهکار رفته در Net Core.
در بالای BCL (بخش Collections)، ایپیآیهای ویژه برنامه قرار دارند. بهطور نمونه، در طرف Net Native. تعدادی ایپیآی از قبیل WinRT در اختیار داریم که ویژه توسعه برنامههای ویندوز هستند. در طرف ASP.Net 5 مجموعه ایپیآیهایی از قبیل MVC قرار دارند که ویژه توسعه وب در سمت سرور هستند. در مجموع، NetCore. به Net Native. یا ASP.Net 5 اختصاص ندارد و BCL و Runtime نیز برای اهداف همهمنظوره و بهصورت ماژولار طراحی شدهاند.
چرا NetCore. منبع باز شد؟
گروه طراحی داتنت دو دلیل بزرگ برای منبع باز شدن NetCore. ارائه کرد:
1- ارائه یک راهکار چندپلتفرمی برای داتنت،
2- ساخت اکوسیستمی قدرتمندتر.
بهمنظور ایجاد راهحل چند پلتفرمی، گروه طراحی تصمیم گرفت از یک روش پایدار برای این منظور استفاده کند که به منبع باز شدن NetCore. منجر شد. گروه طراحی از تجربیات گذشته درسهای خوبی دریافت کرده بود و بهخوبی به این مسئله اشراف داشت که عامل کلیدی در موفقیت پروژه منبع باز مشارکت گروهی است. جنبه کلیدی پیادهسازی یک فرآیند توسعه شفاف و باز، مشارکت دادن طراحان، بازبینی، خواندن مستندات و درج این تغییرات روی یک محصول است.
اگر مؤلفههای اساسی همچون مجموعهها نیازمند چند بار پیادهسازی باشند، این فعالیت به اکوسیستم ضربه میزند. منبع باز بهراحتی امکان توسعه داتنت در قالب یک راه حل چندپلتفرمی را فراهم میکند. هدف از NetCore. داشتن یک کد واحد و پایهای است که میتواند برای ساخت برنامهها مورد استفاده قرار گیرد و توسط پلتفرمهای مختلف مثل ویندوز، لینوکس و Mac OS X پشتیبانی شود.
البته بعضی از مؤلفههای اصلی همچون سیستمفایلی لازم است از پیادهسازی متفاوتی استفاده کنند. مدل توسعه NuGet به گروه طراحی اجازه میدهد تا این مسائل را به روش انتزاعی از هم جدا کنند. میتوانیم بستهای NuGet واحد داشته باشیم که چند پیادهسازی مختلف را در خود جای داده است و هر یک به محیط مشخصی اختصاص داشته باشند. با این حال، بخش مهم در پیادهسازی جزییات مؤلفهها قرار دارد. همه مصرفکنندگان تجربه بهکارگیری ایپیآیهای یکپارچهای را خواهند داشت که روی همه پلتفرمها به یک شکل استفاده میشوند.
البته به روش دیگری نیز میتوان به این موضوع نگریست؛ منبع باز که به هدف گروه طراحی برای انتشار مؤلفههای داتنت در یک مدل سریعتر کمک میکند:
ـ منبع باز شبیه ارتباطات بیدرنگ عمل میکند که برای پیادهسازی در یک جهت مفید است.
ـ توزیع بستهها در NuGet.ORG سرعت بالاتری در سطح مؤلفهها بهوجود میآورد.
ـ توزیعها سرعت بالاتری در سطح پلتفرم بهوجود میآورد.
ترکیب این عناصر به گروه طراحی اجازه میدهد تا بخش گستردهای از سرعت و نبوغ را داشته باشند (شکل 4). اگر در گذشته بهعنوان یک طراح داتنت توانایی ساخت و اجرای کدها روی بیشتر ویندوزها در اختیارتان قرار داشت، از این پس این توانایی به ویندوز، لینوکس، Max OS، آیاواس و آندرویید ارتقا پیدا کرده است.
شکل 4: ترکیب این سه مفهوم قدرت پروژه منبع باز را افزایش میدهد.
یک هفته بعد از منبع باز شدن
درست یک هفته بعد از منبع باز شدن NetCore.، بازخوردهای زیادی از طراحان و توسعهدهندگان به مایکروسافت ارائه شد. بهطوریکه ایمولندورتس (مدیر برنامه گروه BCL) اینگونه اظهار نظر کرد: «ما انتظار دریافت این تعداد واکنش مثبت آن هم در یک هفته را نداشتیم. گیتهاب این روزها به خانهای برای منبع باز مبدل شده است. NetCore. را در صدر مخزن گیتهاب قرار داده است.» (شکل 5)
شکل 5: Net Core. در صدر مخزن گیتهاب قرار داشت.
مشارکت جامعه منبع باز
این همه داستان نبود. در این مدت گروه طراحی Net Core. نزدیک به بیست Pull request دریافت کرد (روشی برای ارائه مشارکت و کمک روی یک پروژه توسعه باز است که از یک سیستم توزیع استفاده میکند. یک Pull request زمانی بهوجود میآید که یک طراح درخواست تغییر موضوع روی یک مخزن خارجی ثبت شده را ارائه میکند که اشاره به ثبت این تغییر روی مخزن اصلی دارد.). نخستین Pull request از طرف آدام رالف بود (شکل 6).
شکل 6: نخستین درخواست و مشارکتی که برای بازبینی در یکی از کدهای ارائه شده در Net Core. توسط آدام رالف ارائه شد.
در مجموع، مشارکتهای قابل توجهی از طرف کاربران دریافت شد که در ارتباط با بهبود کارایی روی مجموعههای تغییرناپذیر متمرکز بودند (شکل 7).
شکل 7: نرخ مشارکتی که بهصورت داخلی و خارجی در ارتباط با CoreFX ارائه شده است.
در بعضی از این مشارکتها، اضافه شدن ایپیآیهای جدیدی درخواست شده بود. از قبیل Async overloads for XDocument که در نهایت XElement.LoadAsync و XDocument.LoadAsync را به XLinq اضافه کرد. هنوز هم در حال بررسی فرآیند اضافه کردن ایپیآیهای عمومی و تیم طراحی Net Core. بهشدت درباره ایجاد یک ارتباط و تعادل مابین NetFramework. و NetCore. محتاط است. در نتیجه، تیم طراحی Net Core. در اینباره واقعبینانه کار خواهد کرد و تعدادی از ایپیآیها به بستر چهارچوب داتنت بازخواهند گشت. هرچند فرآیند ساده و کمهزینهای نخواهد بود. اما این رویکرد بهگونهای نخواهد بود که حرکت Net Core. را با کندی همراه سازد. تمرکز اصلی تیم طراحی روی جنبههای کلیدی پروژه متمرکز هستند.فرآیند مشارکت: تیم طراحی فرآیند نصب یک سرور CI روی AppVeyor را بهپایان رسانده و شروع به ثبت اطلاعات طراحان کرده است. در مرحله بعد، یک نقشه راه و اطلاعات تخصصیتر پیرامون اینکه چگونه Pull request مورد بررسی قرار میگیرد، ارائه خواهیم کرد.
شکل 8: مراحلی که برای یک Pull request یا بازبینی توسط کاربران باید انجام شود.
کتابخانههای بیشتر: کار روی سیستم مهندسی Net. در جریان است تا امکان استخراج و انتشار کتابخانهها روی گیتهاب فراهم شود.چندپلتفرمی: تیم طراحی در حال تعامل با میگوئل و جامعه Mono است. اکنون به دلیل نبود کتابخانههای کافی مسدود شده است، اما بهزودی این مشکل برطرف خواهد شد.
زمان اجرا: بعضی از شما ممکن است مشتاق خواندن کدهای GC یا JIT باشید، اما به احتمال زیاد تا سال آینده باید منتظر بمانید.
// Copyright (c) Microsoft. All rights reserved.
// Licensed under the MIT license. See LICENSE file in the project root for full license information.
using System;
internal class Program
{
private static void Main(string[] args)
{
if (args.Length == 1 && args[0] == "linux")
{
DrawLinux();
}
else if (args.Length == 1 && args[0] == "mac")
{
DrawMac();
}
else
{
DrawWindows();
}
Console.WriteLine();
Console.WriteLine("Press ENTER to exit ...");
Console.ReadLine();
}
private static void DrawWindows()
{
Console.WriteLine("Hello، Windows...");
const int squareSize = 20;
var colors = new[] { ConsoleColor.Red، ConsoleColor.Green، ConsoleColor.Blue، ConsoleColor.Yellow };
for (int row = 0; row < 2; row++)
{
for (int i = 0; i < squareSize / 2; i++)
{
Console.WriteLine();
Console.Write(" ");
for (int col = 0; col < 2; col++)
{
Console.BackgroundColor = colors[row * 2 + col];
Console.ForegroundColor = colors[row * 2 + col];
for (int j = 0; j < squareSize; j++) Console.Write('@');
Console.ResetColor();
}
}
}
Console.WriteLine();
}
private static void DrawLinux()
{
Console.WriteLine("Hello، Linux...");
const string Penguin = @"
@@@@@
@@@@@@@@@@
@@@@@@@@@@@@@
@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@
@@@ @@@@@@@ @@@@@
@@ @@@@ @@@@@
@@ @@ @@ @@ @@@@
@@ @@ @@@ @@@ @@@@
@ @@---- @@@ @@@@
@ @-------@ @@@@@
@------------@@@@@
@------------@@@@@
@------------@@@@@
@------------@@@@@
@ --------- @@@@@@
@ ------ @@@@@@@
@@ -- @@@@@@
@@@ @@@@@@@
@@ @@@@@@
@@@ @@@@@@@
@@@ @@@@@@@
@@@@ @@@@@@@@
@@@@@ @@@@@@@@@
@@@@@ @@@@@@@@
@@@@ @@@@@@@@
@@@@ * @@@@@@@@
@@@@ **** @@@@@@@@
@@@ ***** @@@@@@@@
@@@@ * ****** @@@@@@@@
@@@ ** *** *** @@@@@@@@
@@@@ ******* *** @@@@@@@@@
@@@@ * **** *** @@@@@@@@@
@@@@@ ******* *** @@@@@@@@@
@@@@@ ** *** *** @@@@@@@@@
@@@@@ * ****** @@@@@@@@@
@@@@@ ***** @@@@@@@@@
---@@ **** @@@@@@@@
-----@@ * ---@@@@@@@
------@@ ----@@@@@@--
------------@@ ---@@@@@@--
------------@@@@ ----@@@@----
-------------@@@@ -------------
--------------@@@@ --------------
--------------@@@@ ---------------
---------------@@@ @----------------
---------------- @@-----------------
---------------- @@@-----------------
------------------ @@@@@----------------
------------------@@ @@@@@@@@--------------
-------------------@@@@@@@@@@@@@@------------
------------------@@@@@@@@@@@@@@----------
--------------@@@@@@@@@@@@@@@---------
@---------@ @-------
@----@@ @@-----
@@ @@@
";
foreach (char c in Penguin)
{
if (c == '\n')
{
Console.ResetColor();
Console.WriteLine();
}
else
{
ConsoleColor cc =
c == '*' ? ConsoleColor.Blue :
c == '@' ? ConsoleColor.Black :
c == '-' ? ConsoleColor.Yellow :
ConsoleColor.White;
Console.BackgroundColor = cc;
Console.ForegroundColor = cc;
Console.Write(" ");
}
}
Console.ResetColor();
Console.WriteLine();
}
private static void DrawMac()
{
Console.WriteLine("Hello، Mac...");
const string Apple = @"
،++
@@@@@@+
@@@@@@@@
@@@@@@@@@:
@@@@@@@@@.
:@@@@@@@@
@@@@@@;
`
،@@@@@@@@@@@: @@@@@@@@@@@@@:
:@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@:
:@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
:@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
#@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
:@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@'
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@`
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
:@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@;
@@@@@@@; ;@@@@@@@";
Console.ForegroundColor = ConsoleColor.White;
Console.Write(Apple);
Console.ResetColor();
Console.WriteLine();
}
}
NetCore. بهروزرسانی شد
در یادداشتی که در تاریخ 28 ژانویه در وبلاگ MSDN منتشر شد، اطلاعات جالبی درباره بهروزرسانی اخیری که روی Net Core. انجام شده و کارهایی که در آینده انجام خواهد شد، نوشته شده است. در ادامه چکیدهای از این یادداشتها را مرور خواهیم کرد.
یک مشکل خوب؛ انشعابهای زیادی وجود دارد
چند گروه وظیفه بررسی نظرسنجیها را برعهده دارند. بهدلیل اینکه سرمایهگذاری زیادی در این حوزه انجام شده است، با توجه به تغییراتی که در این سالها بهوجود آمده است، باید با دنیای واقعی همگام بود. امروزه برای سرویسدهی توسعه مستمر الگوی رایجی است. در نتیجه، صنعت با ابزارها و معیارهای مختلف، سلامتی این خدمات را بررسی میکند. اما چرا این موضوع ضروری است؟ به دلیل اینکه لازم است بدانید یک مشکل چه زمانی رخ میدهد و نه زمانی که اتفاق افتاده است.بهتر است با گذشت زمان تنظیمات و تغییرات کوچکی اعمال شوند، بهجای آنکه تغییرات ناگهانی هرچند بسیار کمخطرناکتر بهوجود آید. این روند شناسایی ممکن است در طی زمان تغییر کند. منبع باز هیچ تفاوتی با این دیدگاه ندارد.
مرور ایپیآی
تیم طراحی زمان زیادی برای طراحی ایپیآیها سپری کرد، برای اطمینان از این موضوع که ایپیآیها کاملاً قابل استفاده بوده و الگوهای انتشار یافته پرقدرت و سازگار با نسخههای قبلی ارائه شوند. روشی که تیم طراحی از آن استفاده کرد بر مبنای مستندسازی کارها و بررسی این موضوع که چه الگویی برای طراحی آیپیآیها مفید هستند قرار داشت. این اطلاعات بهصورت عمومی در کتاب «راهنمایی طراحی چهارچوب» (Framework Design Guidelines) نوشته معمار تیم طراحی کریستوف کوالینا منتشر شده است.
تحلیلهای ایستا: تجزیه و تحلیل ایستا (بهطور رسمی FxCop)
برای پیدا کردن نقصهای مشترک، از قبیل نامگذاریهای نادرست یا دنبال نکردن الگوهای منتشر شده مورد استفاده قرار گرفت.
مرور ایپیآی: در بالاترین سطح، مجموعهای از متخصصان ایپیآی اقدام به بازبینی تکتک آنها کردند.
فرآیند بازبینی ایپیآیها برای NetCore.
در تاریخ 19 دسامبر، یادداشتی در گیتهاب قرار گرفت که در فراخوانی از کاربران برای ارائه پیشنهاد درباره فرآیند بازبینی ایپیآیها نظرخواهی شد. در این فراخوان، روی سه اصل طراحی ویژه گیتهاب، مؤثر بودن و شفافیت تأکید شده بود. گیتهاب بهطور کلی بر مبنای مدل Pull request کار میکند (شکل 9). ایدهای که در آن مشارکتکنندگان تغییراتی که بر مبنای سلیقه خودشان است، پیشنهاد داده و یک درخواست ثبت تغییر برای مخزن Pull request میکنند. البته در مواقعی که مشارکتکنندگان ایرادی را بیابند یا درباره کارهای آینده ایدهای دارند، ابتدا باید عنوان بحث و گفتوگو ایجاد کنند. کار روی اضافه شدن ایپیآیها با هدف کاربردی بودن انجام میشود و از کدهای سادهای استفاده میشود که کاربردی بودن سناریو را توضیح دهد. منظور کامل بودن یک ایپیآی نیست، بلکه نشان دادن مسیری است که خوانندگان درباره این پیشنهاد قضاوت کنند. نمونهای درست از این درخواست اینجا قرار دارد.
شکل 9: نمایی از مخزن CoreCLR که روی گیتهاب قرار گرفته است.
CoreCLR منبع باز شد
CoreCLR اکنون بهصورت منبع باز روی گیتهاب قرار گرفته است. CoreCLR موتور اجرایی داتنت در NetCore. بهشمار میرود که وظایفی همچون Garbage Collection و کامپایل کدها به زبان ماشین را انجام میدهد. NetCore. یک ماژولار پیادهسازی شده از داتنت است که بهعنوان یک زیربنا برای مجموعه گستردهای از سناریوهای مختلف منبع باز میتواند مورد استفاده قرار گیرد. امروزه این مقیاس از ابزارهای کنسول تا برنامههای وب روی کلاود را شامل میشود. برای آگاهی یافتن از تفاوت NetCore. با Net Framework. به اینجا مراجعه کنید. تیم طراحی بهطور کامل و بهروز پیادهسازی CoreCLR را منتشر کرد که شامل Net GC ،RyuJIT. و مؤلفههای مختلف محیط زمان اجرای داتنت است. این نسخه در ادامه نسخههای قبلی کتابخانههای پایهای است که هر دو نشاندهنده تعهد زیاد تیم طراحی برای به اشتراکگذاری یک پیادهسازی چندپلتفرمی داتنت است. امروزه NetCore. روی ویندوز ساخته و اجرا میشود (شکل 10).
شکل 10: تعداد دستورات CoreCLR همراه کدهای دیگر
پیادهسازی لینوکس و مک را با مؤلفههای خاص هر پلتفرم در چند ماه آینده اضافه کرد. در گذشته تعداد محدودی از کدهای خاص لینوکس در Net Core. پیادهسازی شد، اما تیم طراحی در شروع راه است. مخزن CoreCLR شباهت زیادی به مخزن CoreFX دارد که چند ماه قبل با آن آشنا شدید. به لحاظ اندازه، مخزن CoreCLR از 2.6 میلیون خط تشکیل شده است. از این تعداد، JIT حدود 320k و GC حدود 55k آن را تشکیل میدهند. مخزن CoreFX با 500k خط که فقط در حدود 25 درصد آن را تشکیل میدهد، بهاشتراک قرار گرفت. شاید گفتن این جمله کمی ترسناک باشد که این دو مخزن در دو مجموع 5 میلیون خط از NetCore. را تشکیل میدهند که اکنون بهطور کامل روی گیتهاب قرار گرفتهاند. این دو مخزن تفاوت کلیدی دارند. CoreFX بهطور کامل در ارتباط با سیشارپ قرار دارد (شکل 11)، در حالی که CoreCLR را مجموعه بزرگی از کدهای سیشارپ و سیپلاسپلاس تشکیل میدهند.
شکل 11: نخستین تصویر ارائه شده از خروجی NetCore.
مخزن CLR به چند ابزار برای ساخت هر دو کدهای سیشارپ و سیپلاسپلاس احتیاج دارد. ابزارهایی که همراه با ویژوال استودیو عرضه نمیشوند، CMake نمونهای از این ابزارها بهشمار میرود. CMake راه حل چندپلتفرمی منحصر بهفردی است که برای ساخت پروژههای منبع باز در محیط محلی مورد استفاده قرار میگیرد. CMake مجموعهای از ابزارها است که برای ساخت، آزمایش و بستهبندی نرمافزارها استفاده میشود. همچنین، برای کنترل فرآیند کامپایل از یک پلتفرم ساده و کامپایلری با فایلهای پیکربندی مستقل استفاده میکند. شرکت کیتویر CMake را در پاسخ به درخواستی که نیازمند یک راه حل چندپلتفرمی برای ساخت پروژههای منبع باز همچون ITK (سرنام Insight Toolkit) و VTK (سرنام Visualization Toolkit) بود، طراحی کرد. البته نسخههای تجاری این ابزار بههمراه پشتیبانی از آموزشهای قوی توسط کیتویر ارائه شده است. برای این منظور CMake یک سیستم ساخت منبع باز چندپلتفرمی را ارائه میدهد.
تیم طراحی به سیستمی نیاز دارد که روی سیستمعاملهای ویندوز، لینوکس و مک بتوان از آن استفاده کرد.
ساخت برنامهها با استفاده از NetCore.
مشاهده همزمان منبع باز بودن NetCore. و پیادهسازی چندپلتفرمی بودن عالی است، اما ممکن است کمی تعجب کنید که چه نوع از برنامههایی با استفاده از این سیستم میتوان ایجاد کرد. تیم طراحی در حال کار روی دو نوع از این برنامهها است و شما هم میتوانید آنها را مورد آزمایش قرار دهید. این برنامهها عبارتند از:
ــ سرویسها و برنامههای وب ASP.Net 5،
ــ برنامههای کنسول.
درباره ASP.Net 5 به تفصیل سخن گفته شده است. برنامههای ASP.Net 5 با استفاده از چهارچوب داتنت یا NetCore. قابل ایجاد هستند. امروز ASP.Net 5 از Mono Runtime روی لینوکس و مک استفاده میکند. زمانی که NetCore. از لینوکس و مک پشتیبانی کند، ASP.Net 5 به استفاده از NetCore. روی آن پلتفرمها حرکت خواهد کرد. تیم طراحی می خواهد این امکان را با ساخت مخزن برای CoreFX و CoreCLR عملی سازد و از این مصنوعات ساخته شده در برنامههای ASP.Net 5 استفاده کند. البته به دلیل بعضی تفاوتهای فنی این امر در حال حاضر امکانپذیر نیست، اما در حال کار روی آنها است. بهتر است توانایی ساخت انشعابهای خود را با تغییراتی که خود پیادهسازی میکنید تجربه و از نتایج بهدست آمده در برنامههای خود استفاده کنید.برنامههای نوع کنسول نمونهای خیلی عالی از نحوه کاربری CoreCLR را نشان میدهند که به شما الگوی بسیار انعطافپذیری برای ساخت هر نوع برنامهای میدهد که نیاز دارید. تقریباً تمام زیرساختهای آزمایشی تیم طراحی از این نوع برنامهها منشعب میشوند. البته شما میتوانید نوع سفارشی CoreCLR مورد نظر خود را ایجاد و برنامههای کنسول را روی آن اجرا کنید.
برنامههای کنسول NetCore.
در حال حاضر، نوع برنامههای کنسول NetCore. محصولی فرعی در فرآیند مهندسی تیم طراحی بهشمار میرود. در ماههای آینده، بهطور کامل پشتیبانی از انواع برنامهها، شامل الگوها و خطایابی در ویژوال استودیو توسط تیم طراحی انجام خواهد شد. همچنین، پشتیبانی خوبی از OmniSharp در برنامههای کنسول بهعمل خواهد آمد (OmniSharp از خانواده پروژههای منبع باز بهشمار میرود که با هدف توسعه داتنت بر مبنای انتخاب کاربران ساخته شده است). تیم طراحی بر این باور است که شما ابزارهای کنسول مختلفی برای ویندوز، لینوکس و مک خواهید ساخت. همچنین، توانایی ایجاد ابزارهای چندپلتفرمی را که روی هر سه سیستمعامل اجرا شوند، تنها با یک باینری خواهید داشت.
نخستین پیشنمایش کنسول از NetCore. روی ویندوز که بر مبنای پیادهسازی منبع باز CoreCLR روی گیتهاب قرار گرفته است، در شکل 11 نشان داده شده است.
نگاهی عمیقتر به برنامه کنسول
سادهترین راه برای پی بردن به CoreCLR از طریق بررسی نمونه اولیه برنامه کنسولی است که بر پایه CoreCLR ساخته شده است. کدهای این برنامه در مخزن جدید CoreFXlab قرار دارند. برای استفاده از این برنامه میتوانید آن را کپی و ایجاد و از طریق خط فرمان زیر آن را اجرا کنید.
git clone https://github.com/dotnet/corefxlab
cd .\corefxlab\demos\CoreClrConsoleApplications\HelloWorld
nuget restore
msbuild
.\bin\Debug\HelloWorld.exe
البته هنگامی که مخزن را کپی میکنید، بهسادگی میتوانید فایل HelloWorld.sln را باز و کدهای آن را در ویژوال استودیو ویرایش کنید. البته به این نکته توجه داشته باشید که شما هنوز قادر به خطایابی نیستید. اما همچنان میتوانید CoreCLR و نسخه محلی برنامه کنسول را اجرا کنید. کدهای برنامه HelloWorld.cs در گیتهاب در نشانی زیر قرار دارند:
سورس کد اصلی قرار گرفته روی گیتهاب در فهرست شماره 1 آورده شده است. در این مرحله، خودکارسازی برنامه کار خارقالعادهای محسوب نمیشود، اما نشان میدهد چگونه میتوانید آن را بهطور دستی با سورس کدهایی که ساختهایم آزمایش کنید.
1- CoreCLR را آن گونه که تصور میکنید، ویرایش کنید.
2- CoreCLR را از طریق build.cmd x64 release ایجاد کنید.
3- فایلهایی که در مسیر coreclr\binaries\x64\release قرار دارند را به مسیر زیر کپی کنید.
corfxlab\demos\CoreClrConsoleApplications\HelloWorld\NotYetPackages\CoreCLR
4- Helloworld.sln را یک بار Rebuild کنید (این کار میتواند از طریق خط فرمان یا ویژوال استودیو انجام شود).
در پایان
تیم طراحی هنوز برای چندپلتفرمی کردن Net. کارهای زیادی در دست انجام دارد. در مرحله بعد، در ماه مارس 2015 میلادی کنفرانس مجازی Net. برگزار میشود. تیم طراحی امیدوار است در این کنفرانس نمونههای بیشتری را به اشتراک قرار دهد.
منابع:
1- OmniSharp - Cross platform .NET development
2- Introducing .NetCore
3- One Week of Open Source
4- CoreCLR is now Open Source
5- .NetCore Open Source Update
6- CMake
7- pullrequest
8- Fix vector tests to work on non en-US culture machines
9- API Review Process
10- API review process for .NetCore
ماهنامه شبکه را از کجا تهیه کنیم؟
ماهنامه شبکه را میتوانید از کتابخانههای عمومی سراسر کشور و نیز از دکههای روزنامهفروشی تهیه نمائید.
ثبت اشتراک نسخه کاغذی ماهنامه شبکه
ثبت اشتراک نسخه آنلاین
کتاب الکترونیک +Network راهنمای شبکهها
- برای دانلود تنها کتاب کامل ترجمه فارسی +Network اینجا کلیک کنید.
کتاب الکترونیک دوره مقدماتی آموزش پایتون
- اگر قصد یادگیری برنامهنویسی را دارید ولی هیچ پیشزمینهای ندارید اینجا کلیک کنید.
نظر شما چیست؟