این چارچوب متن باز با الهام گرفتن از WPF و پشتیبانی از XAML و Visual Studio Designer در حال توسعه است
11 ویژگی بهره وری برای توسعه دهندگان در Visual Studio 2013
عرضه سریع بروز رسانی جدید Visual Studio 2013 نشان از عزم جدی مایکروسافت برای توسعه این IDE را دارد. 
بهتر است قبل از این که به ادامه‌ی آموزش بپردازم، دو نکته را متذکر شوم:
1) روند آموزشی این فریمورک از کل به جز است؛ به این معنا که ابتدا تمامی قابلیت‌های اصلی فریمورک را به صورت کلی و بدون وارد شدن به جزئیات بیان می‌کنم و پس از آن، جزئیات را در قالب مثال‌هایی واقعی بیان خواهم کرد.
2) IDE مورد استفاده بنده Visual Studio 2012 است. همچنین از ابتدا پروژه را با ASP.NET MVC شروع می‌کنم. شاید بگویید که می‌شود Angular را بدون درگیر شدن با مباحث ASP.NET MVC بیان کرد؛ اما پاسخ من این است که این مثال‌ها باید قابل پیاده‌سازی در نرم‌افزارهای واقعی باشند و یکی از بسترهای مورد علاقه‌ی من ASP.NET MVC است. اگرچه باز هم تاکید می‌کنم که کلیه‌ی مباحث ذکرشده، برای کلیه‌ی زبان‌های سمت سرور دیگر هم قابل استفاده است و هدف من در اینجا بیان یک سری چالش‌ها در ASP.NET MVC است.
نحوه‌ی دریافت AngularJS
1) NuGet Package Manager
2) دریافت از وب‌سایت angularjs.org
دریافت از طریق Nuget Package Manager
روش ارجح افزودن کتابخانههای جانبی در یک پروژه‌ی واقعی، استفاده از NuGet Package Manager است. دلیل آن هم بارها بیان‌شده است از جمله: باخبر شدن از آخرین به‌روزرسانی کتابخانه‌ها، دریافت وابستگی‌های کتاب‌خانه‌ی مورد نظر و نبودن محدودیت تحریم برای دریافت فایل‌ها است.
روش کار هم بسیار ساده است، کافی است که بر روی پروژه کلیک راست کرده و گزینه‌ی Manage NuGet Packages را انتخاب کنید و با جست جو angularjs نسبت به نصب آن اقدام نمایید.
اگر هم با ابزارهای گرافیکی رابطه‌ی خوبی ندارید، می‌توانید از Package Manager Console فراهم‌شده توسط NuGet استفاده کنید. کافی است در کنسول پاورشل آن عبارت زیر را تایپ کنید:
Install-Package angularjs
پس از نصب angularjs، شاهد تغییراتی در پوشه‌ی Scripts پروژه‌ی خودخواهید بود. تعداد زیادی فایل جاوا اسکریپت که با عبارت angular شروع‌شده‌اند، به این پوشه اضافه شده است. در حال حاضر ما تنها به فایل angular.js نیاز داریم و احتیاجی به فایل‌های دیگر نیست.
همچنین یک پوشه به نام i18n نیز اضافه شده است که برای مباحث Globalization و Internationalization به کار گرفته می‌شود.
دریافت از سایت angularjs.org
برای دریافت Angular از وب سایت رسمی‌اش، به angularjs.org مراجعه کنید؛ اما گویا به دلیل تحریم‌ها این سایت برای IP ایران مسدود شده است (البته افرادی نیز بدون مشکل به آن دسترسی دارند). دکمه‌ی Download را فشار داده و در نهایت کلید دریافت را بزنید. اگر نسخه‌ی کامل آن را دریافت کنید، لیستی از مستندات AngularJS را نیز در فایل دریافتی، خواهید داشت. در هر صورت این روش برای استفاده از angular دریک پروژه‌ی واقعی توصیه نمی‌شود.
پس به عنوان یک best practice، همیشه کتابخانههای جانبی را با NuGet دریافت و نصب کنید. رفع موانع تحریم‌ها، یکی از مزایای مهم آن است.
پس از دریافت angular، نوشتن برنامه‌ی معروف Hello, World به وسیله‌ی آن ، می‌تواند بهترین شروع باشد؛ اما اگر اجازه بدهید، نوشتن این برنامه را در قالب توضیح قالب‌های سمت کلاینت انجام دهیم.
قالب‌های سمت کلاینت (Client Side Templates)
در برنامه‌های وب چند صفحه‌ای و یا اکثر وب سایت‌های معمول، داده‌ها و کدهای HTML، در سمت سرور اصطلاحا سرهم و مونتاژ شده و خروجی نهایی که HTML خام است به مرورگر کاربر ارسال می‌شود. با یک مثال بیشتر توضیح می‌دهم: در ASP.NET MVC معمولا از لحظه‌ای که کاربر صفحه‌ای را درخواست می‌کند تا زمانی که پاسخ خود را در قالب HTML می‌بیند، این فرآیند طی می‌شود: ابتدا درخواست به Controller هدایت می‌شود و سپس اطلاعات مورد نیاز از پایگاه داده خوانده‌شده و در قالب یک Model به View که یک فایل HTML ساده است، منتقل می‌شود. سپس به کمک موتور نمایشی Razor، داده‌ها در جای مناسب خود قرار می‌گیرند و در نهایت، خروجی که HTML خام است به مرورگر کلاینت درخواست‌کننده ارسال می‌شود تا در مرورگر خود نتیجه را مشاهده نماید. روال کار نیز در اکثر SPAهای معمول و یا اصطلاحا برنامه‌های AJAX، باکمی تغییر به همین شکل است.
اما در Angular داستان به شکل دیگری اتفاق می‌افتد؛ Angular قالب HTML و داده‌ها را به صورت جداگانه از سرور دریافت می‌کند و در مرورگر کاربر آنها را سرهم و مونتاژ می‌کند. بدیهی است که در اینجا قالب، یک فایل HTML ساده و داده‌ها می‌تواند به فرم JSON باشد. در نتیجه کار سرور دیگر فراهم کردن قالب و داده‌ها برای کلاینت است و بقیه‌ی ماجرا در سمت کلاینت رخ می‌دهد.
خیلی خوب، مزیت این کار نسبت به روش‌های معمول چیست؟ اگر اجازه بدهید این را با یک مثال شرح دهم:
در بسیاری از سایت ها، ویژگی ای به نام اسکرول نامحدود وجود دارد. در همین سایت نیز دکمه ای با عنوان بیشتر در انتهای لیستی از مطالب، برای مشاهده‌ی ادامه‌ی لیست قرار گرفته است. سعی کنید پس از فشردن دکمه‌ی بیشتر، داده‌های دریافتی از سرور را مشاهده کنید. پس از انجام این کار مشاهده خواهید کرد که پاسخ سرور HTML خام است. اگر تعداد 10 پست از سرور درخواست شود، 10 بار محتوای HTML تکراری نیز دریافت خواهد شد؛ در صورتی که ساختار HTML یک پست هم کفایت می‌کرد و تنها داده‌ها در آن 10 پست متفاوتند؛ چرا که قالب کار مشخص است و فقط به ازای هر پست باید آن داده‌ها در جای مناسب خود قرار داد.
دیدگاه‌های یک پست هم به خوبی با Angular قابل پیاده سازی است. قالب HTML یک دیدگاه را برای angular تعریف کرده و داده‌های مناسب که احتمالا JSON خام است از سرور دریافت شود. نتیجه‌ی این کار هم صرفه جوی در پهنای باند مصرفی و افزایش فوق العاده‌ی سرعت است، همچنین در صورت نیاز میتوان داده‌ها و قالب‌ها راکش کرد تا مراجعه به سرور به حداقل برسد.
چگونگی انجام این کار در AngularJs به صورت خلاصه به این صورت است که در angular یک directive به نام ng-repeat تعریف شده است که مانند یک حلقه‌ی foreach برای HTML عمل می‌کند. شما در داخل حلقه، قالب را مشخص می‌کنید و به ازای تعداد داده‌ها، آن حلقه تکرار می‌شود و بر روی داده‌ها پیمایش صورت می‌گیرد.
البته این مثال‌ها فقط دو نمونه از کاربرد این ویژگی در دنیای واقعی بود و مطمئن باشید که در مقالات آینده مثال‌های زیادی از این موضوع را پیاده‌سازی خواهیم کرد.
بهتر است که دیگر خیلی وارد جزئیات نشویم و اولین برنامه‌ی خود را به کمک angularjs بنویسیم. این برنامه، همان برنامه‌ی معروف Hello ,World است؛ اما در این برنامه به جای نوشتن یک Hello, World ساده در صفحه، آن را با ساختار angularjs پیاده‌سازی می‌کنیم.
در داخل ویژوال استادیو یک فایل HTML ساده ایجاد کنید و کدهای زیر را داخل آن بنویسید.
<!DOCTYPE html>
<html ng-app>
<head>
<title>Sample 1</title>
</head>
<body>
<div ng-controller="GreetingController">
<p>{{greeting.text}}, World!</p>
</div>
<script src="../Scripts/angular.js"></script>
<script>
function GreetingController($scope) {
$scope.greeting = {
text: "Hello"
};
}
</script>
</body>
</html>سپس فایل فوق را در مرورگر اجرا کنید. بله؛ عبارت Hello, World را مشاهده خواهید کرد. یک بار دیگر خاصیت text را در scope.greeting$ به hi تغییر بدهید و باز هم نتیجه را مشاهده کنید.
این مثال در نگاه اول خیلی ساده است، اما دنیایی از مفاهیم angular را در بر دارد. شما خواص جدیدی را برای عناصر HTML مشاهده می‌کنید: ng-app، ng-controller، آکلود‌ها و عبارت درون آن و متغیر scope$ به عنوان پارامتر.
حال بیایید ویژگی‌ها و مفاهیم جالب کدهای نوشته شده را بررسی کنیم؛ چرا که فرصت برای بررسی ng-app و بقیه‌ی موارد نا آشنا زیاد است:
- هیچ id و یا class برای عناصر html در نظر گرفته نشده تا با استفاده از آنها، رویدادی را برای عناصر مورد نظر مشخص کنیم.
- وقتی در GreetingController مقدار greeting.text را مشخص کرده ایم، باز هم هیچ رویدادی را صدا نزده و یا مشخص نکرده ایم.
- GreetingController یک کلاس ساده‌ی جاوا اسکریپت (POJO) است و از هیچ چیزی که توسط angular فراهم شده باشد، ارث بری نکرده است.
- اگر به متد سازنده‌ی کلاس GreetingController دقت کنید، متغیر scope$ به عنوان پارامتر تعریف شده است. نکته‌ی جالب این است که ما هیچ گاه به صورت دستی سازنده‌ی کلاس GreetingController را صدا نزده ایم و حتی درون سازنده هم scope$ را ایجاد نکرده ایم؛ پس چگونه توانسته ایم خاصیتی را به آن نسبت داده و برنامه به خوبی کار کند. بهتر است برای پاسخ به این سوال خودتان دست به کار شوید؛ ابتدا نام متغیر scope$ را به نام دلخواه دیگری تغییر دهید و سپس برنامه را اجرا کنید. بله برنامه دیگر کار نمی‌کند. دلیل آن چیست؟ همان طور که گفتم Angular دارای یک سیستم تزریق وابستگی توکار است و در اینجا نیز scope$ به عنوان وابستگی در سازنده‌ی این کلاس مشخص شده است تا نمونه‌ی مناسب آن توسط angular به کلاس GreetingController ما تزریق شود؛ اما چرا به نام آن یعنی scope$ حساس است؟ به این دلیل که زبان جاوا اسکریپت یک زبان پویا است و نوع در آن مطرح نیست؛ angular مجبور است که از نام پارامترها برای تزریق وابستگی استفاده می‌کند. در مقالات آینده چگونگی عملکرد سیستم تزریق وابستگی angular را به تشریح بیان می‌کنم.
- همچنین همان طور که در مورد قبلی نیز به آن اشاره کردم، ما هیچ گاه خود دستی سازنده‌ی GreetingController را صدا نزدیم و جایی نیز نحوه‌ی صدا زدن آن را مشخص نکرده ایم.
تا همین جا فکر کنم کاملا برای شما مشخص شده است که ساختار فریمورک Angular با تمامی کتاب خانه‌های مشابه متفاوت است و با ساختاری کاملا اصولی و حساب شده طرف هستیم. همچنین در مقالات آینده توجه شما را به قابلیت‌هایی بسیار قدرتمند‌تر جلب خواهم کرد.
MVC ،MVP ، MVVM و یا MVW
در بخش اول این مقاله، الگوی طراحی پیشنهادی فریمورک Angular را MVC بیان کرده‌ام؛ اما همان طور که گفته بودم AngularJS از انقیاد داده دوطرفه (Two Way Data Binding) نیز به خوبی پشتیبانی می‌کند و به همین دلیل عده ای آن را یک MVVM Framework تلقی می‌کنند. حتی داستان به همین جا ختم نمی‌شود و عده ای آن را به چشم MVP Framework نیز نگاه می‌کنند. در ابتدا سایت رسمی AngularJS الگوی طراحی مورد استفاده را MVC بیان می‌نمود ولی در این چند وقت اخیر عنوانش را به MVW Framework تغییر داده است.
MVW مخفف عبارت Model View Whatever هست و کاملا مفهومش مشخص است. Model و View بخش‌های مشترک تمام الگو‌ها بودند و تنها بخش سوم مورد اختلاف توسعه دهندگان بود؛ در نتیجه انتخاب آن را بر عهده‌ی استفاده کننده قرار داده اند و تمام امکانات لازم برای پیاده‌سازی این الگوهای طراحی را فراهم کرده اند. در طی این مقالات صرف نظر از تمام الگوهای طراحی فوق، من بیشتر بر روی MVC تمرکز خواهم کرد.
الگوی طراحی MVC در سال 1970 به عنوان بخشی از زبان برنامه نویسی Smalltalk معرفی شد و از همان ابتدا به سرعت محبوبیت زیادی در بین محیط‌های توسعه‌ی دسکتاپی از قبیل ++C و Java که رابط کاربری گرافیکی به نوعی در آنها دخیل است، پیدا کرد.
تفکر MVC این را بیان می‌کند که باید جداسازی واضح و روشنی بین مدیریت داده‌ها (Model)، منطق برنامه (Controller) و نمایش داده‌ها به کاربر (View) وجود داشته باشد و در اصل هدفش جداسازی اجزای رابط کاربری به بخش هایی مجزا است.
شاید این سوال برای شما پیش بیاید که چرا باید چنین الگویی را در برنامه‌ها پیاده کرد؟
احتمالا تا کنون از بین برنامه هایی که نوشته اید، رابط کاربری بیشتر از آنها را نیز خودتان مجبور شده اید طراحی کنید؛ به این دلیل که برنامه‌ی شما بدون رابط کاربری قابل اجرا شدن نبوده است. اجرای برنامه‌ی شما منوط به وجود تعدادی دکمه و textbox و ... بوده است و به قولی منطق برنامه به رابط گرافیکی گره خورده بوده است. پس میتوان گفت که پیاده‌سازی الگوی طراحی وقتی ضرورت پیدا می‌کند که رابط گرافیکی، قسمتی از برنامه‌ی شما را تشکیل دهد.
آیا با وجود زبان‌های طراحی ساده ای مثل HTML و XAML و ... احتیاجی است که برنامه نویس وقت خود را صرف طراحی رابط کاربری کند؟ مسلما خیر، چون دیگر با این امکانات یک طراح هم از پس این کار به خوبی و یا حتی بهتر بر می‌آید. دیگر وظیفه‌ی برنامه نویس نوشتن کدهای مربوط به منطق برنامه است. کدهایی که بدون UI هم قابل تست شدن باشد و به راحتی بتوان برای آنها آزمون‌های واحد نوشت. برنامه نویس باید این را در نظر بگیرد که UI وجود ندارد و حتی ممکن است هیچ گاه هم ایجاد نشود و این کدها تبدیل به یک کتابخانه شود و مورد استفاده قرار بگیرد تا در یک برنامه با رابط کاربری گرافیکی.
در MVC، روال عمومی کار به این شکل است که View داده‌ها را از Model دریافت می‌کند و به کاربر نمایش می‌دهد. وقتی که کاربر با کلیک کردن و تایپ کردن با برنامه ارتباط برقرار می‌نماید، Controller به این درخواست‌ها پاسخ می‌دهد و داده‌های موجود در Model را به روز رسانی می‌کند. در نهایت هم Model تغییرات خود را به View منعکس می‌کند تا View آن چه را که پیش از آن نمایش می‌داده است، تغییر دهد و View را از تغییرات رخ داده آگاه نماید.
اما در برنامه‌های Angular قضیه از چه قرار است؟ در Angular، قالب HTML یا اگر بخواهم دقیق‌تر بگویم (Document Object Model(DOM معادل View است؛ کلاس‌های جاوا اسکریپتی نقش Controller را دارند؛ و خواص اشیای جاوا اسکریپتی و یا حتی خود اشیا نقش Model را بر عهده دارند.
ساختار بخشیدن به برنامه با استفاده MVC یک مزیت مهم دیگر نیز دارد: ساختار کار کاملا مشخص است و هر کسی نمی‌تواند به صورت سلیقه ای آن را پیاده سازی کند. با یک مثال این موضوع را تشریح می‌کنم: اگر کسی پروژه‌ی بنده را که با ASP.NET MVC نوشتم، بررسی کند، اصلا احساس غریبی نمی‌کند و به راحتی می‌تواند آن را توسعه دهد. دلیل این موضوع این است که ASP.NET MVC یک ساختار مشخص را به توسعه دهندگان اجبار کرده است و هر کسی این ساختار را رعایت کند و با آن آشنا باشد، به راحتی می‌تواند با آن کار کند. توسعه دهنده می‌داندکه من Model را کجا تعریف کرده ام، Controller مربوط به هر View کجاست و در کدام قسمت با پایگاه داده ارتباط برقرار کرده‌ام؛ اما در مورد کدهای JavaScript و سمت کلاینت چه طور؟ توسعه دهنده ای که می‌خواهد کار من را ادامه بدهد دچار وحشت می‌شود! الگوی مشخصی وجود ندارد؛ معلوم نیست که کجا DOM را دستکاری کرده‌ام، در کدام قسمت با سرور ارتباط برقرار شده و... به قول معروف با یک اسپاگتی کد تمام عیار طرف می‌شود. AngularJS این مشکل را حل نموده و ساختار خاصی را سعی کرده به شما دیکته کند و تا حد ممکن دست شما را نیز باز گذاشته است. جدا از همه‌ی اینها، برنامه‌های مبتنی بر Angular به راحتی نگه داری و تست می‌شوند و بدون هیچ دغدغه ای آنها را میتوان توسعه داد.
در حاشیه
شاید در هنگام دریافت فایل angularjs و افزودن آن به پروژه‌ی خود شروع به اعتراض کرده اید که نسخه‌ی فشرده شده‌ی آن 87 کیلو بایت حجم دارد در صورتی که این حجم در کتابخانههای مشابه ممکن است حتی به 10 کیلوبایت هم نرسد. اگر دقت کرده باشید من در بیان AngularJS از واژه‌ی کتاب خانه استفاده نکردم و فقط از واژه‌ی فریمورک استفاده کردم. بله نمی‌شود angular را با کتاب خانه هایی مقایسه کرد که مهمترین ویژگی خود را Data Binding می‌دانند. AngularJS یک بستر کاری قدرتمند است که تمام راه حل‌های موجود را در خود جمع کرده است. تیم توسعه دهنده‌ی آن هم هیچ ادعایی ندارد و می‌گویند که ما هیچ چیزی را خودمان اختراع نکرده ایم، بلکه راه حل‌های عالی را برگزیدیم، تفکرهای خوب را ارتقا بخشیده و در فریمورک خود استفاده کردیم و حتی از ایده‌های خوب دیگر کتاب خانه‌ها هم استفاده کرده ایم. بنابر این نباید به حجم آن در مقابل توانایی هایی که دارد اعتراض کرد.
همچنین به نظر می‌آید که AngularJS یک فریمورک پیچیده است. ولی من همیشه بین پیچیده و پیچیده شده تفاوت قائل می‌شوم. به نظر شخصی خودم Angular به دلیل مشکلات خاص و پیچیده ای که حل می‌کند پیچیده است و پیچیده شده نیست. اگر آن را پیچیده شده حس می‌کنید، تنها دلیلش، نحوه‌ی آموزش دادن بنده است، تمام سعی خود را می‌کنم که مفاهیم را تا حد ممکن ساده بیان کنم و امیدوارم در آینده که با مثال‌های بیشتری روبرو می‌شوید، این مفاهیم به کارتان بیاید.
در مقاله‌ی بعدی به مفاهیم انقیاد داده، تزریق وابستگی، هدایت گر‌ها (Directives) و سرویس‌ها در AngularJS می‌پردازم.
با سلام
در پاسخ به مشکل شما چند نکته باید اشاره بشه. نکته اول: ماکروی TargetFileName فقط اسم فایل خروجی پروژه رو برمی‌گردونه، درصورتیکه برای کارکردن دستور فوق مسیر کامل فایل نیازه. چون برنامه editbin.exe درون مسیر خروجی پروژه شما اجرا نمی‌شه. شما می‌تونین از ماکروی TargetPath استفاده کنید که مسیر کامل فایل خروجی پروژه رو برمی‌گردونه.
نکته دوم: کد خطای 9009 مربوط به پیدا نکردن فایل هست. البته فایلی که در اینجا پیدا نشده خروجی پروژه شما نیست بلکه خود ابزار editbin هستش. مسیر درستش در سیستم 32 بیتی برای ویژوال استودیو 2010 اینه:
C:\Program Files\Microsoft Visual Studio 10.0\VC\bin\editbin.exe
اما چون این مسیرها معمولا حاوی فاصله هستند نیاز به استفاده از دابل کوتیشن در ابتدا و انتها وجود داره. بنابراین دستور کامل باید به صورت زیر باشه:
"C:\Program Files\Microsoft Visual Studio 10.0\VC\bin\editbin.exe" /STACK:1000000 "$(TargetPath)"
اما با اجرای دستور فوق باز هم خطایی صادر میشه که کمی خطرناکتر از قبلیه. و اما دلیلش:
نکته سوم: متن زیر از msdn گرفته شده:
You can start this tool only from the Visual Studio command prompt. You cannot start it from a system command prompt or from Windows Explorer.
البته منظور دقیق‌تر این جمله اینه که ابزار editbin نیاز به یکسری تنظیمات و متغیرهای ازپیش تعیین شده داره که در Visual Studio command prompt انجام شده. اما نگران نباشید برای تنظیم این تنظیمات و تبدیل خط فرمان Build Events در ویژوال استودیو به یک Visual Studio command prompt کافیه که خط زیر رو در ابتدای مجموعه دستورات build events خودتون قرار بدین:
call "$(DevEnvDir)..\Tools\vsvars32.bat"
این بچ فایل حاوی دستوراتی نسبتا مفصل برای تنظیم تنظیمات موردنیاز است. درواقع با اجرای این بچ فایل هر خط فرمانی تقریبا تبدیل به Visual Studio command prompt خواهد شد. با توجه به ماکروی (DevEnvDir)$ مسیر کامل این فایل در سیستم 32 بیتی و برای ویژوال استودیوی 2010 به صورت زیر است:
C:\Program Files\Microsoft Visual Studio 10.0\Common7\Tools\vsvars32.bat
بنابراین برای کار کردن دستور موردنظر شما کافیه که این دو دستور به صورت زیر در Post Build Event اضافه بشه:
call "$(DevEnvDir)..\Tools\vsvars32.bat" "C:\Program Files\Microsoft Visual Studio 10.0\VC\bin\editbin.exe" /STACK:1000000 "$(TargetPath)"
نکته چهارم: با توجه به اشاره‌ای که در نکته قبلی شد ("با اجرای این فایل هر خط فرمانی تقریبا تبدیل به Visual Studio command prompt خواهد شد.") بنابراین دستور فوق را میتوان به صورت زیر خلاصه کرد:
call "$(DevEnvDir)..\Tools\vsvars32.bat" "editbin.exe" /STACK:1000000 "$(TargetPath)"
موفق باشید.
من با Management Studio ی SQL Server 2008 همین (localdb)\v11.0 رو وارد کردم و متصل شد. مطمئن هستید که فقط با SQL 2012 میشه بهش وصل شد؟
زمانیکه به صفحه‌ی دریافت نگارشهای مختلف NET Core. مراجعه می‌کنیم، بسته‌های مختلفی از یک نگارش قابل مشاهده هستند و در بدو امر واضح نیست که کدامیک را باید دریافت کرد. در این مطلب تفاوت‌های بین این بسته‌ها را مرور خواهیم کرد.
کدام نگارشهای NET Core. بر روی سیستم شما نصب هستند؟
پیش از انجام هرکاری نیاز است بررسی کنیم کدامیک از بسته‌های ارائه شده، بر روی سیستم جاری نصب هستند. برای انجام اینکار دستور زیر را در خط فرمان صادر کنید:
اگر این دستور کار نکرد و خطایی را دریافت کردید، یعنی NET Core. اصلا بر روی سیستم شما نصب نیست. برنامه dotnet.exe جزئی از runtime نصب شده‌است و به صورت خودکار به path سیستم اضافه می‌شود. به همین جهت است که در صورت نصب آن، فرمان dotnet در هر مسیری قابل اجرا است.
Runtime تنها ویژگی‌های اساسی جهت اجرای برنامه‌های از پیش کامپایل شده‌ی NET Core. را با اجرای فرمانی مانند dotnet mydll.dll و یا اجرای دستور dotnet --info برای دریافت اطلاعاتی از جزئیات این ویژگی‌ها، به همراه دارد. اما برای کار با سورس کدها، build، publish و هر کار دیگری با آنها، حتما باید SDK نیز نصب شود.
خروجی فرمان فوق بر روی سیستم من چنین چیزی است:
اولین شماره نگارش نمایش داده شده‌ی در این لیست (2.1.301)، شماره نگارش SDK فعال است. سپس شماره نگارش 2.1.1 به معنای شماره نگارش Runtime فعال بر روی سیستم است که هاست dotnet.exe به شمار می‌رود. سپس لیست SDKها و Runtimeهای نصب شده‌ی بر روی سیستم را نمایش می‌دهد.
باید دقت داشت که بر روی یک سیستم میتوان چندین SDK و چندین Runtime مختلف را نصب کرد و هر پروژه از شماره نگارش خاصی استفاده کند. شماره نگارش runtime استفاده شده‌ی در پروژه‌ها در فایل csproj، توسط مدخل زیر مشخص می‌شود:
در مورد SDK اینطور نیست و همواره از آخرین SDK نصب شده (همان شماره نگارش SDK فعال فوق) استفاده می‌شود، مگر اینکه فایل ویژه‌ای به نام global.json را در ریشه‌ی اصلی solution قرار دهید؛ با این محتوای فرضی:
در این حالت پروژه‌ی جاری را وادار می‌کنید بجای استفاده‌ی از آخرین SDK نصب شده‌ی بر روی سیستم، از نگارش SDK خاصی استفاده کند.
البته در اکثر موارد نیازی به انجام این کار نیست؛ چون SDK، با تمام نگارشهای قبلی سازگار است و همواره استفاده‌ی از آخرین SDK نصب شده توصیه می‌شود. به همین جهت فایل global.json را پس از ایجاد یک solution جدید مشاهده نمی‌کنید؛ مگر اینکه خودتان به دلایل خاصی آن‌را اضافه و مقید نمائید.
تفاوت بسته‌های مختلف قابل دریافت NET Core. در چیست؟
زمانیکه برای دریافت آخرین نگارش NET Core. به سایت آن مراجعه می‌کنیم، به ازای هر نگارش، یک چنین لیستی قابل مشاهده است:
و اکنون سؤالی که مطرح می‌شود این است: کدامیک را باید دریافت کرد؟
Visual Studio
اگر کاربر ویندوز هستید، با نصب آخرین نگارش Visual Studio، می‌توانید به همراه آن، آخرین نگارش SDK ،runtime و اجزای هاست برنامه‌های ASP.NET Core بر روی IIS را نیز بر روی سیستم خود نصب کنید.
NET Core SDK.
هدف از ارائه‌ی بسته‌ی SDK، انجام فرآیندهای build، اجرا و مدیریت امور مرتبط با NET Core.، بدون استفاده از Visual Studio و بر روی تمام سیستم عامل‌های پشتیبانی شده‌است. زمانیکه یک بسته‌ی SDK را نصب می‌کنید، به همراه آن این موارد نیز نصب می‌شوند:
به همین جهت حجم آن از بسته‌ی تکی runtime بیشتر است و با نصب آن دیگر نیازی به دریافت مجزای بسته‌های runtime نیست.
بنابراین دلیل نصب آن می‌تواند شامل یکی از موارد زیر باشد:
- بر روی سیستمی که در حال توسعه‌ی برنامه‌های مبتنی بر NET Core. هستید. این تمام چیزی است که به آن نیاز دارید.
- بر روی سروری که نیاز است دستور dotnet را برای انجام فرآیندهای build/publish اجرا کند.
NET Core Runtime.
بسته‌های Runtimes، کوچکترین بسته‌ی ممکن در این لیست هستند و هدف از آنها صرفا اجرای برنامه‌های کامپایل شده‌ی NET Core. در سکوهای کاری مختلف پشتیبانی شده‌ی توسط آن است.
باید دقت داشت که اگر برنامه‌ی شما از «ASP.NET Core meta package» استفاده می‌کند، این بسته در runtime لحاظ نشده‌است و در یک چنین حالتی باید بسته‌ی ASP.NET Core را به صورت جداگانه دریافت و نصب کنید. هرچند اگر از این متاپکیج‌ها استفاده نکنید و بسته‌های مورد نیاز را به صورت مستقیم به برنامه‌ی خود اضافه کنید، این بسته‌ها جزئی از فایل‌های publish نهایی بوده و در این حالت برنامه توسط بسته‌ی runtime نیز قابل اجرا است.
در این حالت برنامه‌ی dotnet بجز اجرای برنامه‌ها و ارائه‌ی اطلاعاتی در مورد خود آن، کارهای دیگری را مانند build و یا publish، نمی‌تواند انجام دهد و برنامه در این حالت باید کاملا از پیش کامپایل شده باشد.
بنابراین دلیل نصب آن می‌تواند شامل یکی از موارد زیر باشد:
- برای اجرای برنامه‌های از پیش کامپایل شده‌ای که به همراه تمام وابستگی‌های مورد نیاز هم هستند.
- برای اجرای برنامه‌های وبی که از ASP.NET Meta packages استفاده نمی‌کنند
ASP.NET Core Installer
همانطور که در توضیحات بسته‌ی runtime عنوان شد، این بسته، متاپکیج‌های ASP.NET Core را به همراه ندارد. اگر به آنها نیاز دارید، باید آنها را به صورت جداگانه توسط ASP.NET Core installer نصب کنید که شامل این موارد است:
NET Core Windows Hosting Pack.
نصب این بسته برای هاست برنامه‌های ASP.NET Core در ویندوز و بر روی IIS ضروری است و شامل این اجزا می‌شود:
بنابراین این بسته شامل تمام موارد یاد شده‌است منهای قابلیت‌های SDK برای build و publish برنامه‌ها.
بنابراین به صورت خلاصه
برای سرورها این موارد را نصب کنید:
- در ویندوز: Windows Server Hosting Bundle
- برای Mac و لینوکس: .NET Core Runtime + ASP.NET Core Runtimes
برای سیستم توسعه‌ی شخصی این موارد را نصب کنید:
- SDK
- اگر از ویندوز استفاده می‌کنید: Visual Studio هم به همراه SDK نصب می‌شود.
برای اجرای برنامه‌های از پیش کامپایل شده که به همراه تمام وابستگی‌های مورد نیاز هم هستند:
- تنها Runtime را نصب کنید.
اگر این برنامه‌ی از پیش کامپایل شده از ASP.NET Runtime Meta packages استفاده می‌کند:
- ASP.NET Runtimes را نیز نصب کنید.
کدام نگارشهای NET Core. بر روی سیستم شما نصب هستند؟
پیش از انجام هرکاری نیاز است بررسی کنیم کدامیک از بسته‌های ارائه شده، بر روی سیستم جاری نصب هستند. برای انجام اینکار دستور زیر را در خط فرمان صادر کنید:
dotnet --info
Runtime تنها ویژگی‌های اساسی جهت اجرای برنامه‌های از پیش کامپایل شده‌ی NET Core. را با اجرای فرمانی مانند dotnet mydll.dll و یا اجرای دستور dotnet --info برای دریافت اطلاعاتی از جزئیات این ویژگی‌ها، به همراه دارد. اما برای کار با سورس کدها، build، publish و هر کار دیگری با آنها، حتما باید SDK نیز نصب شود.
خروجی فرمان فوق بر روی سیستم من چنین چیزی است:
C:\Users\Vahid>dotnet --info .NET Core SDK (reflecting any global.json): Version: 2.1.301 Commit: 59524873d6 Runtime Environment: OS Name: Windows OS Version: 10.0.17134 OS Platform: Windows RID: win10-x64 Base Path: C:\Program Files\dotnet\sdk\2.1.301\ Host (useful for support): Version: 2.1.1 Commit: 6985b9f684 .NET Core SDKs installed: 2.1.300 [C:\Program Files\dotnet\sdk] 2.1.301 [C:\Program Files\dotnet\sdk] .NET Core runtimes installed: Microsoft.NETCore.App 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 2.1.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] To install additional .NET Core runtimes or SDKs: https://aka.ms/dotnet-download
باید دقت داشت که بر روی یک سیستم میتوان چندین SDK و چندین Runtime مختلف را نصب کرد و هر پروژه از شماره نگارش خاصی استفاده کند. شماره نگارش runtime استفاده شده‌ی در پروژه‌ها در فایل csproj، توسط مدخل زیر مشخص می‌شود:
<TargetFramework>netcoreapp2.1</TargetFramework>
{
"sdk": {
"version": "2.1.300-rc.31211"
}
} البته در اکثر موارد نیازی به انجام این کار نیست؛ چون SDK، با تمام نگارشهای قبلی سازگار است و همواره استفاده‌ی از آخرین SDK نصب شده توصیه می‌شود. به همین جهت فایل global.json را پس از ایجاد یک solution جدید مشاهده نمی‌کنید؛ مگر اینکه خودتان به دلایل خاصی آن‌را اضافه و مقید نمائید.
تفاوت بسته‌های مختلف قابل دریافت NET Core. در چیست؟
زمانیکه برای دریافت آخرین نگارش NET Core. به سایت آن مراجعه می‌کنیم، به ازای هر نگارش، یک چنین لیستی قابل مشاهده است:
• .NET Core Runtime • .NET Core SDK • .NET Core Hosting Bundle • Visual Studio • ASP.NET Core Installer
Visual Studio
اگر کاربر ویندوز هستید، با نصب آخرین نگارش Visual Studio، می‌توانید به همراه آن، آخرین نگارش SDK ،runtime و اجزای هاست برنامه‌های ASP.NET Core بر روی IIS را نیز بر روی سیستم خود نصب کنید.
NET Core SDK.
هدف از ارائه‌ی بسته‌ی SDK، انجام فرآیندهای build، اجرا و مدیریت امور مرتبط با NET Core.، بدون استفاده از Visual Studio و بر روی تمام سیستم عامل‌های پشتیبانی شده‌است. زمانیکه یک بسته‌ی SDK را نصب می‌کنید، به همراه آن این موارد نیز نصب می‌شوند:
• .NET Core SDK • .NET Core Runtime • ASP.NET Core Runtime
بنابراین دلیل نصب آن می‌تواند شامل یکی از موارد زیر باشد:
- بر روی سیستمی که در حال توسعه‌ی برنامه‌های مبتنی بر NET Core. هستید. این تمام چیزی است که به آن نیاز دارید.
- بر روی سروری که نیاز است دستور dotnet را برای انجام فرآیندهای build/publish اجرا کند.
NET Core Runtime.
بسته‌های Runtimes، کوچکترین بسته‌ی ممکن در این لیست هستند و هدف از آنها صرفا اجرای برنامه‌های کامپایل شده‌ی NET Core. در سکوهای کاری مختلف پشتیبانی شده‌ی توسط آن است.
باید دقت داشت که اگر برنامه‌ی شما از «ASP.NET Core meta package» استفاده می‌کند، این بسته در runtime لحاظ نشده‌است و در یک چنین حالتی باید بسته‌ی ASP.NET Core را به صورت جداگانه دریافت و نصب کنید. هرچند اگر از این متاپکیج‌ها استفاده نکنید و بسته‌های مورد نیاز را به صورت مستقیم به برنامه‌ی خود اضافه کنید، این بسته‌ها جزئی از فایل‌های publish نهایی بوده و در این حالت برنامه توسط بسته‌ی runtime نیز قابل اجرا است.
در این حالت برنامه‌ی dotnet بجز اجرای برنامه‌ها و ارائه‌ی اطلاعاتی در مورد خود آن، کارهای دیگری را مانند build و یا publish، نمی‌تواند انجام دهد و برنامه در این حالت باید کاملا از پیش کامپایل شده باشد.
بنابراین دلیل نصب آن می‌تواند شامل یکی از موارد زیر باشد:
- برای اجرای برنامه‌های از پیش کامپایل شده‌ای که به همراه تمام وابستگی‌های مورد نیاز هم هستند.
- برای اجرای برنامه‌های وبی که از ASP.NET Meta packages استفاده نمی‌کنند
ASP.NET Core Installer
همانطور که در توضیحات بسته‌ی runtime عنوان شد، این بسته، متاپکیج‌های ASP.NET Core را به همراه ندارد. اگر به آنها نیاز دارید، باید آنها را به صورت جداگانه توسط ASP.NET Core installer نصب کنید که شامل این موارد است:
- The ASP.NET Runtime Meta Packages - Microsoft.AspNetCore.App - Microsoft.AspNetCore.All
نصب این بسته برای هاست برنامه‌های ASP.NET Core در ویندوز و بر روی IIS ضروری است و شامل این اجزا می‌شود:
- 32 bit and 64 .NET Core Runtimes - ASP.NET Runtime Packages (Microsoft.AspNetCode.App/All) - IIS Hosting Components
بنابراین به صورت خلاصه
برای سرورها این موارد را نصب کنید:
- در ویندوز: Windows Server Hosting Bundle
- برای Mac و لینوکس: .NET Core Runtime + ASP.NET Core Runtimes
برای سیستم توسعه‌ی شخصی این موارد را نصب کنید:
- SDK
- اگر از ویندوز استفاده می‌کنید: Visual Studio هم به همراه SDK نصب می‌شود.
برای اجرای برنامه‌های از پیش کامپایل شده که به همراه تمام وابستگی‌های مورد نیاز هم هستند:
- تنها Runtime را نصب کنید.
اگر این برنامه‌ی از پیش کامپایل شده از ASP.NET Runtime Meta packages استفاده می‌کند:
- ASP.NET Runtimes را نیز نصب کنید.
- آغاز کار با WPF
- آشنایی با WPF قسمت اول : ساختار سلسله مراتبی
- آشنایی با WPF قسمت دوم: Layouts بخش اول
- آشنایی با WPF قسمت سوم: Layouts بخش دوم
- آشنایی با WPF قسمت چهارم: کنترل ها
- آشنایی با WPF قسمت پنجم : DataContext بخش اول
- آشنایی با WPF قسمت پنجم : DataContext بخش دوم
- آشنایی با WPF قسمت ششم : DataContext بخش سوم
- انقیاد داده‌ها در WPF بخش اول
- انقیاد داده‌ها در WPF بخش دوم
- آشنایی با الگوی M-V-VM- قسمت اول
- M-V-VM - قسمت دوم
- آشنایی با الگوی M-V-VM - قسمت سوم
- آشنایی با الگوی M-V-VM - قسمت چهارم
- آشنایی با الگوی M-V-VM - قسمت پنجم
- Expression Blend WPF Tutorial
- طول و عرض WPF
- آموزش رایگان XAML از مایکروسافت
- سری آموزشی PRISM
- ویدیوهای رایگان آموزشی WPF
- ارتقاء از WinForms به WPF
- خلاصهای کاربردی در مورد Observable collection
- دو تنظیم ضروری VS.NET جهت کار با WPF و Silverlight
- معرفی WPF Extended toolkit
- WPF و قالبهایی جهت کنترل DataGrid
- خلاصهای از مبحث نمایش اطلاعات hierarchical در WPF
- WPF4 و ویندوز 7 : به خاطر سپاری لیست آخرین فایل‌های گشوده شده توسط برنامه
- نمایش یک فایل PDF در WinForms ، WPF و سیلورلایت
- چند نکته در مورد WPF MediaElement و ویندوز XP
- تعیین Fallback font برای قلمهای فارسی در WPF
- آموزش ایجاد برنامه‌های چند زبانه در WPF
- آشنایی و استفاده از WCF Data Services در Visualstudio 2012
- بارگذاری UserControl در WPF به کمک الگوی MVVM
- معماری لایه بندی نرم افزار #1
- معماری لایه بندی نرم افزار #2
- معماری لایه بندی نرم افزار #3
- معماری لایه بندی نرم افزار #4
- نحوه نمایش تمام آیکونهای تعریف شده در یک قلم در WPF
- نحوه استخراج آیکونهای یک قلم در WPF
- مقیدسازی (DataBinding) در WPF زمانی که دسترسی به DataContext وجود ندارد
- فراخوانی یک متداز یک کنترل WPF از XAML
- آشنایی با Catel MVVM Frameowork
- استفاده از ItemsControl جهت ساختن کنترلهای پویا در WPF
- ساخت فرمهای generic در WPF و Windows Application
- استفاده از #F در پروژه‌های WPF
- Markup Extensions در XAML
- Debug کردن Binding در XAML
- Bind کردن Enum به ItemsSource در XAML
- دسترسی به فیلدهای Static در XAML
- نگاهی به درون سیستم Binding در WPF و یافتن مواردی که هنوز در حافظهاند
- بهبود کارآیی کنترلهای لیستی WPF در حین بارگذاری تعداد زیادی از رکوردها
- چگونه تشخیص دهیم UI Virtualization در WPF خاموش شده است؟
- اضافه کردن امکان ویرایش WPF DataGrid در صورت نامعتبر بودن سلول ها
- انقیاد RadioButtonها در WPF به یک Enum
- یکی کردن اسمبلیهای یک پروژه‌ی WPF
- بستن یک پنجره از طریق ViewModel با استفاده از خصوصیتهای پیوست شده هنگام استفاده از الگوی MVVM
- حرکت روی سلولهای دیتا گرید با فشردن کلید Enter در برنامه‌های WPF
- دسترسی به Collectionها در یک ترد دیگر در WPF
- آموزش WAF
- آموزش WAF (بررسی ساختار همراه با پیاده سازی یک مثال)
- آموزش WAF (بررسی Commandها)
- آموزش WAF (مشاهده تغییرات خواص ViewModel در Controller)
- تصادفی کردن آیتمهای لیست با استفاده از Extension Method
- استفاده از AvalonEdit در WPF
- فرمت شرطی اطلاعات به کمک تریگرها در WPF
- first chance exception چیست؟
- معرفی کتاب‌خانه‌ی OxyPlot
- معرفی DNTProfiler
- چگونه برنامه‌های دات نت را خارج از ویژوال استودیو دیباگ کنیم؟
- اسکرول روان لیستهای مجازی سازی شده در WPF 4.5
- پیاده سازی INotifyPropertyChanged با استفاده از Unity Container
این مطلب دنباله‌ی «تغییر عملکرد و یا ردیابی توابع ویندوز با استفاده از Hookهای دات نتی» است.
روش ارائه شده در آن با ویندوزهای XP تا 7 نگارشهای 32 بیتی و 64 بیتی، بدون مشکل کار می‌کند. اما تاثیری بر روی ویندوز 8 و نگارشهای پس از آن نداشت.
تغییرات توابع GetDateFormatW و GetTimeFormatW در ویندوز اکسپلورر ویندوز 8
چه برنامه‌ی ExplorerPCal و چه API Monitor را اگر با فعال سازی توابع GetDateFormatW و GetTimeFormatW اجرا کنید، هیچ خروجی خاصی را مشاهده نخواهید کرد. در ابتدا به نظر می‌رسد که ساختار ویندوز شاید تغییر کرده‌است ... ولی اینطور نیست. فقط اینبار بجای فراخوانی این توابع از kernel32.dll، از یک dll مخفی در پوشه‌ی System32 استفاده می‌شود. روش پیدا کردن آن نیز به صورت زیر است:
کار dumpbin.exe موجود در پوشه‌ی VC\bin ویژوال استودیو، استخراج import table و export table یک فایل اجرایی و یا یک dll بومی ویندوز است. به این ترتیب میتوان دریافت یک فایل exe، از چه dll هایی استفاده می‌کند و همچنین از این dllها، کدامیک از توابع آنها را مورد استفاده قرار داده است.
اگر خروجی این برنامه را که اکنون در فایل explorer.imports.txt ذخیره شده‌است، بررسی کنیم، به نتیجه‌ی زیر خواهیم رسید:
بله. در ویندوزهای سری 8، دیگر از کرنل32 برای دریافت GetDateFormatW استفاده نمی‌شود. اینبار از dll ایی به نام api-ms-win-core-datetime-l1-1-1.dll کمک گرفته شده‌است. این dll در پوشه‌ی System32 با خاصیت مخفی قرار دارد.
بنابراین تنها تغییری که باید در برنامه‌ی ExplorerPCal داده شود، اضافه کردن مداخل جدید فوق است. در ویندوزهای قبل از 8، از نگارشهای Ex استفاده نمی‌شد. در اینجا هم از نگارشهای W و هم Ex دار استفاده شده‌است.
اگر خواستید این تغییرات را با برنامه‌ی API Monitor بررسی کنید، فایل جدید api-ms-win-core-datetime-l1-1-1.xml ذیل را در پوشه‌ی API\Windows آن کپی نمائید تا مداخل api-ms-win-core-datetime-l1-1-1.dll نیز به مجموعه‌ی تعاریف آن اضافه شوند.
api-ms-win-core-datetime-l1-1-1.xml
حاصل نهایی، فایل‌های اجرایی و سورس بهبود یافته‌ی برنامه را از اینجا می‌توانید دریافت کنید:
شمسی ساز تاریخ اکسپلورر ویندوز
تاثیر آن‌را نیز بر روی Explorer ویندوز 8، در تصاویر ذیل می‌توانید ملاحظه نمائید:
روش ارائه شده در آن با ویندوزهای XP تا 7 نگارشهای 32 بیتی و 64 بیتی، بدون مشکل کار می‌کند. اما تاثیری بر روی ویندوز 8 و نگارشهای پس از آن نداشت.
تغییرات توابع GetDateFormatW و GetTimeFormatW در ویندوز اکسپلورر ویندوز 8
چه برنامه‌ی ExplorerPCal و چه API Monitor را اگر با فعال سازی توابع GetDateFormatW و GetTimeFormatW اجرا کنید، هیچ خروجی خاصی را مشاهده نخواهید کرد. در ابتدا به نظر می‌رسد که ساختار ویندوز شاید تغییر کرده‌است ... ولی اینطور نیست. فقط اینبار بجای فراخوانی این توابع از kernel32.dll، از یک dll مخفی در پوشه‌ی System32 استفاده می‌شود. روش پیدا کردن آن نیز به صورت زیر است:
"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\dumpbin.exe" /imports c:\windows\explorer.exe > explorer.imports.txt
اگر خروجی این برنامه را که اکنون در فایل explorer.imports.txt ذخیره شده‌است، بررسی کنیم، به نتیجه‌ی زیر خواهیم رسید:
api-ms-win-core-datetime-l1-1-1.dll
14015E848 Import Address Table
1401613E0 Import Name Table
0 time date stamp
0 Index of first forwarder reference
2 GetDateFormatW
1 GetDateFormatEx
4 GetTimeFormatEx بنابراین تنها تغییری که باید در برنامه‌ی ExplorerPCal داده شود، اضافه کردن مداخل جدید فوق است. در ویندوزهای قبل از 8، از نگارشهای Ex استفاده نمی‌شد. در اینجا هم از نگارشهای W و هم Ex دار استفاده شده‌است.
اگر خواستید این تغییرات را با برنامه‌ی API Monitor بررسی کنید، فایل جدید api-ms-win-core-datetime-l1-1-1.xml ذیل را در پوشه‌ی API\Windows آن کپی نمائید تا مداخل api-ms-win-core-datetime-l1-1-1.dll نیز به مجموعه‌ی تعاریف آن اضافه شوند.
api-ms-win-core-datetime-l1-1-1.xml
حاصل نهایی، فایل‌های اجرایی و سورس بهبود یافته‌ی برنامه را از اینجا می‌توانید دریافت کنید:
شمسی ساز تاریخ اکسپلورر ویندوز
تاثیر آن‌را نیز بر روی Explorer ویندوز 8، در تصاویر ذیل می‌توانید ملاحظه نمائید:
ساعت و تقویم نوار وظیفه‌ی ویندوز
تاریخ تغییرات فایل‌ها، در نمایش لیستی ویندوز اکسپلورر
تاریخ ایجاد و تغییرات یک فایل در خواص آن
تاریخ نمایش داده شده به همراه charm bar ویندوز 8
در نظر سنجی که قبلا توسط دوستان درباره میزان آشنایی و استفاده از زبان‌های مختلف برنامه نویسی در تولید پروژه‌های نرم افزاری انجام شده بود (^) تعداد رای زبان #F سه رای بود(یعنی کمتر از یک درصد). یکی از دلایلی که #F کمتر از سایر زبان‌ها مورد توجه است (البته تا این زمان) نبود منبع یا کتاب فارسی در زمینه یادگیری و هم چنین عدم شناخت از امکانات و قدرت این زبان است. در نتیجه تصمیم گرفتم در طی دو یا چند دوره به آموزش برنامه نویسی این زبان بپردازم. دوره اول که از قسمت دوره‌ها (^ )در این سایت در دسترس عموم قرار دارد سطوح مقدماتی و متوسط را پوشش می‌دهد (سرفصل‌های این دوره در قسمت آموزش #F ذکر شده است). به دلیل حجم گسترده مطالب امکان ارایه تمام مفاهیم و روش‌ها در طی یک دوره امکان پذیر نبود در نتیجه تصمیم بر آن شد که با توجه به اولویت‌های آموزشی این مطالب طبقه بندی شوند و طی دو یا چند دوره به دوستان عزیز ارائه شوند.
دوره ای که هم اکنون در دسترس است صرفا جهت آشنایی دوستان با نوع کدنویسی و مفاهیم برنامه نویسی این زبان تهیه شده است اما دوره پیشرفته این زبان که بعدا در طی چند فصل، آموزش داده خواهد شد دارای سرفصل‌های زیر خواهد بود:
دوره ای که هم اکنون در دسترس است صرفا جهت آشنایی دوستان با نوع کدنویسی و مفاهیم برنامه نویسی این زبان تهیه شده است اما دوره پیشرفته این زبان که بعدا در طی چند فصل، آموزش داده خواهد شد دارای سرفصل‌های زیر خواهد بود:
- استفاده از #F در پروژه‌های تولید شده با زبان #C و در محیط Visual Studio.Net
- استفاده از EntityFramework در زبان #F
- تولید و توسعه پروژهای Windows Application با زبان #F
- تولید و توسعه پروژهای WPF با زبان #F
- تولید و توسعه پروژه‌های تحت Silverlight با زبان #F
- و...
موفق باشید.