از دقت کردن در نحوه اداره پروژههای خوب و بزرگ در سطح دنیا، میتوان به نکات آموزندهای رسید. برای مثال NHibernate را درنظر بگیرید. این پروژه شاید روز اول کپی مطابق اصل نمونه جاوای آن بوده، اما الان از خیلی از جهات یک سر و گردن از آن بالاتر است. پشتیبانی LINQ را اضافه کرده، خودش Syntax جدیدی را به نام QueryOver ارائه داده و همچنین معادلی را جهت حذف فایلهای XML به کمک امکانات جدید زبانهای دات نتی مانند lambda expressions ارائه کرده. خلاصه این تیم، فقط یک کپی کار نیست. پایه رو از یک جایی گرفته اما سبب تحول در آن شده. از اهداف پروژههای سورس باز هم همین است: برای هر کاری چرخ را از صفر ابداع نکنید.
اگر به نحوه اداره کلی پروژه NHibernate دقت کنید یک مورد مشهود است:
- تمام گزارشهای باگ بدون Unit test ندید گرفته میشوند.
- از کلیه بهبودهای ارائه شده (وصلهها یا patch ها) بدون Unit test صرفنظر میشود.
- از کلیه موارد جدید ارائه شده بدون Unit test هم صرفنظر خواهد شد.
بنابراین اگر در issue tracker این تیم رفتید و گفتید: «سلام، اینجا این مشکل هست»، خیالتان راحت باشد که ندید گرفته خواهید شد.
سؤال : چرا اینها اینطور رفتار میکنند؟!
- وجود Unit test دقیقا مشخص میکند که چه قسمت یا قسمتهایی به گزارش باگ شما مرتبط هستند. نیازی نیست حتما بتوانید یک خطا را با جملات ساده شرح دهید. این مساله خصوصا در پروژههای بین المللی حائز اهمیت است. ضعف زبان انگلیسی همه جا هست. همینقدر که توانستهاید برای آن یک Unit test بنویسید که مثلا در این عملیات با این ورودی، نتیجه قرار بوده بشود 10 و مثلا شده 5 یا حتی این Exception صادر شده که باید کنترل شود، یعنی مشکل را کاملا مشخص کردهاید.
- وجود Unit tests ، انجام Code review و همچنین Refactoring را تسهیل میبخشند. در هر دو حالت یاد شده، هدف تغییر کارکرد سیستم نیست؛ هدف بهبود کیفیت کدهای موجود است. بنابراین دست به یک سری تغییرات زده خواهد شد. اما سؤال اینجا است که از کجا باید مطمئن شد که این تغییرات، سیستم را به هم نریختهاند. پروژهی جاری چند سال است که در حال توسعه است. قسمتهای زیادی به آن اضافه شده. با نبود Unit tests ممکن است بعضی از قسمتها زاید یا احمقانه به نظر برسند.
- بهترین مستندات کدهای تهیه شده، Unit tests آن هستند. برای مثال علاقمند هستید که NHibernate را یاد بگیرید؟ هرچه میگردید مثالهای کمی را در اینترنت در این زمینه پیدا میکنید؟ وقت خودتان را تلف نکنید! این پروژه بالای 2000 آزمون واحد دارد. هر کدام از این آزمونها نحوهی بکارگیری قسمتهای مختلف را به نحوی کاربردی بیان میکنند.
- وجود Unit tests از پیدایش مجدد باگها جلوگیری میکنند. اگر آزمون واحدی وجود نداشته باشد، امروز کدی اضافه میشود. فردا همین کد توسط عدهای دیگر زاید تشخیص داده شده و حذف میشود! بنابراین احتمال بروز مجدد این خطا در آینده وجود خواهد داشت. با وجود Unit tests، فلسفه وجودی هر قسمتی از کدهای موجود پروژه دقیقا مشخص میشود و در صورت حذف آن، با اجرای آزمونهای خودکار سریعا میتوان به کمبودهای حاصل پیبرد.
Husky.Net v0.0.2 منتشر شد.
ابزاری ایست که به جرات میتونم بگم تمام شرکتها و پروژههای Open-Source و تیمهای متوسط تا بزرگ بهش نیاز دارند. برنامه نویسها JavaScript و بیشتر وب, پکیج هایی با نام husky و lint-staged دارند که به صورت گستره روی بیشتر پروژههای خوبی که دیدم داره ازش استفاده میشه ولی پیش نیازهایی داره که برای دات نت کارها زیاد شاید جالب نباشه. مثل نصب node و yarn و ....
این ابزار امکانات اون پکیج هارو دراختیار برنامه نویسان دات نت میگذاره. (البته فیچر هایی بیشتری هم داره)
تولید داخل هم هست حمایت فراموش نشه D:
اگر نیاز بود در مورد اینکه چرا گفتم تمام شرکتها نیاز دارند بهش نظر بدید سعی میکنم یک مقاله کوچک آماده کنم در این مورد.
- امکان سنجی پروژههای نرمافزاری | | blog.fardapardaz.com
- لینوکس نیازی به آنتی ویروس نداره... | www.negahbaan.com
- پول ویندوز را بدهیم یا ندهیم؟ | (Afshar Mohebbi) | blog.afsharm.com
- دولت آلمان استفاده از بدافزار جاسوسی را تایید کرد | فرهاد جعفری | www.winbeta.net
- زبان برنامه نویسی جدید گوگل : دارت | (مجتبی بنائی) | www.banaie.ir
- گوگل زبان جدید برنامه نویسی را با نام Dart معرفی کرد | www.zoomit.ir
- وضعیت اینترنت پرسرعت پس از رفع محدودیت حجمی | علی پارسا | www.winbeta.net
- EF 4.2 RC منتشر شد | blogs.msdn.com
- Microsoft Security Intelligence Report | www.microsoft.com
- TortoiseSVN-1.7.0 منتشر شد | sourceforge.net
- استفاده از Direct3D 11 در دات نت | blogs.msdn.com
- بررسی EF 4.2 در حالت اول دیتابیس | blogs.msdn.com
- بررسی تازههای EF 4.2 | blogs.msdn.com
- جلوگیری از CSRF حین استفاده از Ajax | feeds.haacked.com
- دات نت 4 و نیم و کاهش ری استارت سیستم در حین نصب آن | channel9.msdn.com
- در مورد سایت جدید ASP.NET نظر دهید | weblogs.asp.net
- دسترسی به MSDN به کمک وب سرویسهای آن | msdn.microsoft.com
در مقاله قبلی ، درباره دلایل استفاده از Xamarin ، کمی صحبت کردیم. حال وقت آن رسیده که به سراغ نصب و راه اندازی اولین پروژه زمارین برویم.
اگر شما از Visual Studio 2015 به بعد استفاده کنید، موقع نصب قادر خواهید بود که با انتخاب گزینه Mobile Development و انتخاب Xamarin ، آن را نصب و همچنین تمامی فایلهای مربوط به آن را دریافت کنید. در نظر داشته باشید که در طول این پروسه شما باید از ف.یل.تر شکن استفاده کنید، چرا که بعضی از فایلها مانند Android Sdk بر روی سرور گوگل قرار دارد و گوگل آپیهای ایران را برای برنامه نویسان فیلتر کرده است (البته اگر بستهی کامل VS 2017 را دریافت کرده باشید، تمام این پیش نیازها، به همراه این بستهی 21~ گیگابایتی موجود است و این مشکلات را نخواهید داشت).
حال اگر در حال حاضر Visual Studio را بر روی سیستم خود نصب دارید و زمارین را نصب نکرده اید میتوانید از طریق خود سایت زمارین اقدام به دانلود آن بکنید. در نظر داشته باشید، وقتیکه فایل نصبی را از سایت دریافت میکنید، برنامه شروع به نصب خودکار زمارین و تمامی موارد مورد نیاز خود میکند که در این مورد هم به ف.یل.تر شکن نیاز دارید (منهای بستهی کامل VS 2017 که پیشتر عنوان شد). همانطور که بالا گفته شد فایل هایی مانند Android Sdk را نمیتوان از آی پی ایران دانلود کرد (مگر اینکه از سایتهای واسط استفاده کنید).
پس از موافقت با حقوق کپی رایت زمارین، سیستم شما
را جستجو کرده و تمامی موارد مورد نیاز را که نیاز به نصب دارند، به شما نشان
داده و نصب خواهد کرد.
اگر همه مراحل با موفقیت به پایان برسد، پیغامی مبنی بر موفقیت آمیز بودن عملیات را دریافت خواهید کرد. اما اگر به هر دلیلی فایل نصبی نتواند فایلهای مورد نیاز را دانلود کند، پیغامی مبنی بر شکست عملیات دانلود فایل مورد نظر را دریافت میکنید. در این صورت میتوانید صفحهای را مشاهده کنید که درون آن تمامی فایلهای دانلود نشده و لینک دانلود مستقیم آنها قرار دارند و شما میتوانید فایلهای offline آنها را دانلود کرده و به صورت دستی بر روی سیستم نصب نمایید.
اگر تمامی فایلهای مورد نظر را دانلود کرده باشید، قادر خواهید بود اولین پروژهی خود را شروع کنید. قبل از اینکه کار با زمارین را شروع کنیم، اجازه دهید از اینکه ویژوال استودیو تمامی فایلهای نصب شده را تشخیص داده یا خیر، مطمئن شویم. ویژوال استودیوی خود را باز کرده و از منوی Tools، گزینهی Options را انتخاب و بعد از باز شدن صفحه مورد نظر، در انتهای لیست، گزینه Xamarin را انتخاب کنید.
اگر تمامی مراحل با موفقیت انجام شده باشند، ویژوال استودیو تمامی فایلها را به صورت خودکار تشخیص خواهد داد. اما اگر ویژوال استودیو به هر دلیلی هر کدام از اینها را تشخیص نداد، ابتدا از نصب بودن آنها اطمینان حاصل نمایید و سپس به صورت دستی مسیر آنها را مشخص کنید.
نکته : در نظر داشته باشید فایلهای زیر برای اجرای برنامه بر روی اندروید میباشند و اگر شما تمایلی به اجرای نرم افزار خود را بر روی اندروید ندارید، میتوانید از آنها صرف نظر کنید.
در این مرحله میخواهیم اولین برنامه زمارین خود را شروع کنیم. همانطور که در مقاله قبلی توضیح داده شد، شما میتوانید از xamarin forms و یا xamarin native استفاده کنید. Xamarin forms ساختاری برای code sharing میباشد که توسط شرکت زمارین توسعه داده شدهاست. به این ترتیب شما قادر خواهید بود که با استفاده از Xamarin Forms با نوشتن کمترین کد، نرم افزار خود را بر روی پلتفرمهای پشتیبانی شدهی توسط زمارین اجرا کنید. استفاده از Xamarin Forms برای یک پروژهی تجاری بسیار مناسب میباشد؛ اما در برخی موارد شما باید از Xamarin Native هم استفاده نمایید که در این صورت هم زمارین دست شما را نخواهد بست و قادر خواهید بود که به صورت ترکیبی از Xamarin Forms و Xamarin Native از آن استفاده نمایید.
حال به سراغ ساخت اولین پروژه زمارین برویم. در ابتدا برای ایجاد یک پروژه، از منوی File گزینه New و سپس گزینه Project را انتخاب کنید. در پنجره باز شده از سمت چپ گزینه C# را انتخاب و از زیر منوی Cross Platform گزینه Cross Platform App را انتخاب کنید.
پس از تایید با صفحه زیر مواجه خواهید شد.
در این قسمت همانطورکه مشاهده میکنید میتوانید از دو نوع قالب استفاده کنید و همانطور که از نام آنها مشخص است، Master Detail دو پروژه خواهد ساخت که میتوانید از آن برای سناریوهای خاص استفاده کنید. در قسمت پایین، UI Technology مشخص کنندهی شیوه پیاده سازی ظاهر برنامه است. زمارین فرم برای پیاده سازی ظاهر برنامه از Xaml استفاده میکند و شما میتوانید از طریق آن ظاهر تمامی پلت فرمها را پیاده کنید. همچنین قادر خواهید بود بجای استفاده از Xaml، از زبانهای مخصوص هر پلتفرم مانند Xml برای اندروید استفاده کرده و ظاهر نرم افزار خود را با استفاده از آن پیاده کنید.
زمارین فرم برای Code Sharing از دو روش استفاده میکند.
Shared Project
مزایا:
· شما به تمامی قسمتهای یک پلتفرم دسترسی دارید.
· قادر خواهید بود کدهایی مخصوص به هر پلتفرم را بنویسید.
· میتوانید با استفاده از Conditional Compilation، بر اساس نوع پلتفرم، شروطی را اعمال نمایید.
معایب:
· شما با این روش نمیتوانید DLL ایی را تولید کنید و از آن در پروژههای دیگر استفاده نمایید.
· نوشتن Unit Testing نسبت به روش Portable پیچیدهتر است.
Portable Class Library
مزایا:
· شما قادر خواهید بود از پروژه خود DLL تهیه کرده و در مابقی پروژهها از آن استفاده کنید.
· نوشتن Unit Test به سادگی امکان پذیر است.
معایب:
· در این روش شما نمیتوانید از کدهای مخصوص به هر پلتفرم ( Platform-Specific ) استفاده کنید (البته با استفاده از Dependency Injection امکان پذیر است).
· فقط قادر خواهید بود که از زیر مجموعه .Net استفاده نمایید.
در ادامه پس از انتخاب Xamarin Forms و Shared Project، بر روی Ok کلیک کنید. همانطور که میبینید ویژوال استودیو شروع به ساخت پروژههای برنامه میکند. اگر تمامی Sdk های مورد نیاز را نصب کرده باشید، ویژوال استدیو 5 پروژه را برای شما میسازد (در نظر داشته باشید که اگر SDK مربوط به Universal Windows Platform را هم نصب کرده باشید، پروژهی مربوط به آن را نیز خواهید دید).
اولین پروژه، پروژه Shared است که کدهای برنامه در این پروژه نوشته خواهد شد.
دومین پروژه همانطور که از پسوند آن مشخص است، پروژه مربوط به اندروید است. در نظر داشته باشید که پروژههایی که مربوط به پلتفرمها میباشند، برای نوشتن کدهای مخصوص به هر پلتفرم در دسترس میباشند و کدهای نوشته شده در این پروژهها و پروژه Shared ترکیب شده و بعد کامپایل میشوند.
در زمارین برنامهها از فایلی به نام App
اجرا میشوند. این فایل علاوه بر دسترسی به Life Cycle اپلیکیشن، وظیفهی دیگر آن مشخص کردن اولین
صفحهی برنامه نیز میباشد. این فایل درون پروژه Shared قرار دارد.
همانطور که مشاهده میکنید پس از باز کردن فایل App، در متد سازنده آن صفحه اصلی، به صفحهای به نام MainPage که یک فایل Xaml میباشد، تنظیم شدهاست. پس از باز کردن فایل MainPage با کدهای زیر مواجه میشویم.
<?xml version="1.0" encoding="utf-8" ?> <ContentPage xmlns="http://xamarin.com/schemas/2014/forms" xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml" xmlns:local="clr-namespace:PreviewerTest" x:Class="PreviewerTest.MainPage"> <Label Text="Welcome to Xamarin Forms!" VerticalOptions="Center" HorizontalOptions="Center" /> </ContentPage>
که مشخص کننده یک لیبل با متن Welcome to Xamarin Forms! میباشد. پس از اجرای برنامه میتوانیم کد اجرا شده را مشاهده کنیم.
LocalDB چیست؟
بسته کامل آنرا از نیوگت دریافت کنید. از اینجا
علاوه بر ارائه درایور دات نتی، حاوی دو پوشه amd64 و x86 کپی شده در پوشه bin برنامه هم خواهد بود (فایلهای native اصل بانک اطلاعاتی). همین پوشهها و فایلها را باید به همراه برنامه نیز ارائه کنید.
هزینه استفاده از دات نت فریم ورک چقدر است؟
نسخه express ویژوال استودیو به گفته خود مایکروسافت هم در سطحی نیست که توسعه دهنده های حرفه ای نرم افزار ازش استفاده کنن و بیشتر برای علاقه مندان و دانشجو ها و یا تست پروژه کاربردش توصیه شده. برای مثال می تونید از همین شرکت های ایرانی فعال در نرم افزار بپرسیم که کدومشون می تونن از نسخه express بدون مشکل استفاده کنن. IDE های دیگر هم برای دات نت به پای ویژوال استودیو نمی رسن اکثرا هم این مورد رو موافقن که بهترین IDE برای دات نت همون ویژوال استودیو هست. اون مورد هم که به صورت دستی کامپایل و دیباگ رو انجام بدیم که به این موضوع بر می گرده که اصلا از IDE استفاده بکنیم یا نه؟ هدف تو دات نت اینه که توسعه دهنده فکر و نیروش روی طراحی و منطق برنامه بگذاره و تا حد امکان درگیر این مسایل نشه بنابراین کار با IDE برای هماهنگی با این موضوع ضروری هست. اگه توسعه دهنده ها بخوان زحمت این ریزه کاری ها رو تحمل کنن خیلی بهتره که به جای دات نت سراغ یه پلتفرم و زبان دیگه برن چون عملا از خیلی از مزایاش استفاده نمی کنن.
در مورد پروژه مونو هم بیشتر میشه گفت این تعریف ها اسم هست تا واقعی. برای مثال میشه به این نگاه کرد که چه پروژه ی بزرگی تا به حال با مونو پیاده سازی شده؟ به جز چند برنامه متن باز و پروژه های کوچیک دیگه شرکتی پیدا نمیشه که بخواد روی مونو سرمایه گذاری کلانی کنه. یکی از دلایل این عدم استقبال از مونو مربوط میشه به ترس از این که امکان داره مایکروسافت با شکایت علیه مونو تمام مجوز های استفاده از اون رو سلب کنه و اون وقته که هر چی رشته بودن پنبه میشه. حتی پروژه های متن باز هم سعی می کنن تا جایی که امکان داره از مونو دوری کنن. واقعا به طور عملی نمیشه فعلا روی مونو حسابی باز کرد مخصوصا از نوع تجاری.
این موارد رو فقط برای این گفتم که با دید بازتری به مساله نگاه کنیم نه این که حرف های شما رو نقض کنم. ولی باید این مورد هم در نظر داشت که با وجود این که سری رایگان محصولات express مایکروسافت و پروژه مونو وجود دارن آیا در یک محیط کاری و تجاری میشه از اون ها استفاده کرد یا خیر. چیزی که تو تقریبا تمام شرکت ها مشاهده می کنیم که که عملا همه از نسخه های پولی ویژوال استودیو و SQL server استفاده می کنن و خبری هم از مونو نیست.
حرف آخرم اینه منظورم این نیست که بگیم باید از مایکروسافت دوری کرد. مایکروسافت یه پلتفرم درست کرده برای یه عده از توسعه دهنده ها که تونسته موفق هم باشه و خیلی ها هم جذب کنه. اتفاقا خیلی هم خوبه که در دات نت توی ایران پر بار هستیم. ولی آیا زبان ها و پلتفرم های دیگه هم به اون جایگاهی که دارن در ایران رسیدن؟ بازار کار دات نت در ایران خوبه اما آیا این تک قطبی شدن بازار به نفع توسعه دهنده یا مشتری هست؟ منابع غیر دات نت در ایران کم هست اما این دلیل میشه که زبان های دیگرو نفی کنیم و همه منابع انگلیسی و دیگر اون ها رو نادیده بگیرم؟ اگه فقط بخوایم به چیزی که جا افتاده هست مهر تایید بزنیم و بقیه رو نادیده بگیریم خب حرفی باقی نمی مونه اما اگه می خوایم دانش کامپیوتر رو گسترش بدیم به بقیه هم باید همون قدر بها بدیم.
با احترام
هزینه استفاده از دات نت فریم ورک چقدر است؟
نسخه express ویژوال استودیو به گفته خود مایکروسافت هم در سطحی نیست که توسعه دهنده های حرفه ای نرم افزار ازش استفاده کنن و بیشتر برای علاقه مندان و دانشجو ها و یا تست پروژه کاربردش توصیه شده. برای مثال می تونید از همین شرکت های ایرانی فعال در نرم افزار بپرسیم که کدومشون می تونن از نسخه express بدون مشکل استفاده کنن. IDE های دیگر هم برای دات نت به پای ویژوال استودیو نمی رسن اکثرا هم این مورد رو موافقن که بهترین IDE برای دات نت همون ویژوال استودیو هست. اون مورد هم که به صورت دستی کامپایل و دیباگ رو انجام بدیم که به این موضوع بر می گرده که اصلا از IDE استفاده بکنیم یا نه؟ هدف تو دات نت اینه که توسعه دهنده فکر و نیروش روی طراحی و منطق برنامه بگذاره و تا حد امکان درگیر این مسایل نشه بنابراین کار با IDE برای هماهنگی با این موضوع ضروری هست. اگه توسعه دهنده ها بخوان زحمت این ریزه کاری ها رو تحمل کنن خیلی بهتره که به جای دات نت سراغ یه پلتفرم و زبان دیگه برن چون عملا از خیلی از مزایاش استفاده نمی کنن.
در مورد پروژه مونو هم بیشتر میشه گفت این تعریف ها اسم هست تا واقعی. برای مثال میشه به این نگاه کرد که چه پروژه ی بزرگی تا به حال با مونو پیاده سازی شده؟ به جز چند برنامه متن باز و پروژه های کوچیک دیگه شرکتی پیدا نمیشه که بخواد روی مونو سرمایه گذاری کلانی کنه. یکی از دلایل این عدم استقبال از مونو مربوط میشه به ترس از این که امکان داره مایکروسافت با شکایت علیه مونو تمام مجوز های استفاده از اون رو سلب کنه و اون وقته که هر چی رشته بودن پنبه میشه. حتی پروژه های متن باز هم سعی می کنن تا جایی که امکان داره از مونو دوری کنن. واقعا به طور عملی نمیشه فعلا روی مونو حسابی باز کرد مخصوصا از نوع تجاری.
این موارد رو فقط برای این گفتم که با دید بازتری به مساله نگاه کنیم نه این که حرف های شما رو نقض کنم. ولی باید این مورد هم در نظر داشت که با وجود این که سری رایگان محصولات express مایکروسافت و پروژه مونو وجود دارن آیا در یک محیط کاری و تجاری میشه از اون ها استفاده کرد یا خیر. چیزی که تو تقریبا تمام شرکت ها مشاهده می کنیم که که عملا همه از نسخه های پولی ویژوال استودیو و SQL server استفاده می کنن و خبری هم از مونو نیست.
حرف آخرم اینه منظورم این نیست که بگیم باید از مایکروسافت دوری کرد. مایکروسافت یه پلتفرم درست کرده برای یه عده از توسعه دهنده ها که تونسته موفق هم باشه و خیلی ها هم جذب کنه. اتفاقا خیلی هم خوبه که در دات نت توی ایران پر بار هستیم. ولی آیا زبان ها و پلتفرم های دیگه هم به اون جایگاهی که دارن در ایران رسیدن؟ بازار کار دات نت در ایران خوبه اما آیا این تک قطبی شدن بازار به نفع توسعه دهنده یا مشتری هست؟ منابع غیر دات نت در ایران کم هست اما این دلیل میشه که زبان های دیگرو نفی کنیم و همه منابع انگلیسی و دیگر اون ها رو نادیده بگیرم؟ اگه فقط بخوایم به چیزی که جا افتاده هست مهر تایید بزنیم و بقیه رو نادیده بگیریم خب حرفی باقی نمی مونه اما اگه می خوایم دانش کامپیوتر رو گسترش بدیم به بقیه هم باید همون قدر بها بدیم.
با احترام
NET Standard. در حقیقت یک قرار داد است که سکوهای کاری مختلف دات نتی مانند Full .NET Framework ، Xamarin ، Mono ، UWP و غیره میتوانند آنرا پیاده سازی کنند. یک نمونهی دیگر این پیاده سازیها نیز NET Core. است. برای مثال دات نت 4.6.1، استاندارد و قرار داد شمارهی 2 دات نت را پیاده سازی میکند. به همین صورت NET Core 2.0. نیز پیاده سازی کنندهی این استاندارد شماره 2 است.
«اما» باید درنظر داشت که دات نت استاندارد، بیش از یک قرار داد چیزی نیست و پیاده سازی کنندگان آن میتوانند سطح بیشتری را نسبت به این قرار داد نیز لحاظ کنند. برای مثال دات نت 4.6.1 شامل سطح API بیشتری از دات نت استاندارد 2 است.
با تغییرات اخیر، اکنون NuGet میتواند کتابخانههای مبتنی بر NET Standard 2. را در برنامههای مبتنی بر سکوهای کاری که آنرا پیاده سازی میکنند، بدون مشکل اضافه کند. برای مثال میتوان اسمبلیهای دات نت 4.6.1 را به برنامههای ASP.NET Core 2.0 اضافه کرد (کاری که در نگارش 1x آن به صورت مستقیم میسر نیست) و یا میتوان اسمبلیهای کامپایل شدهی برای دات نت استاندارد 2 را به برنامههای مبتنی بر دات نت 4.6.1 اضافه کرد.
«اما» باید درنظر داشت که امکان اضافه کردن یک بستهی نیوگت از یک کتابخانهی نوشته شدهی برای دات نت کامل در برنامههای دات نت Core به معنای تضمینی برای کار کردن آن در زمان اجرا نخواهد بود. از این جهت که دات نت کامل، به همراه قسمتهایی است که در NET Standard. وجود خارجی ندارند. بنابراین اگر کتابخانهی استفاده شده صرفا این API مشترک را هدف قرار دادهاست، هم قابلیت اتصال و هم قابلیت اجرا را خواهد داشت؛ اما اگر برای مثال کسی بستهی NServiceBus را به پروژهی ASP.NET Core 2.0 اضافه کند، بدون مشکل کامپایل خواهد شد. اما از آنجائیکه این کتابخانه از MSMQ استفاده میکند که خارج از میدان دید این استاندارد است، در زمان اجرا با شکست مواجه خواهد شد.