بازخوردهای دوره
آشنایی با مدل برنامه نویسی TAP
با سلام
آیا دات نت 4.5 رو میشه روی xp نصب کرد ؟ 
دات نت 4 را روی xp sp2  با نصب کامپوننت Window Imaging Component میشد نصب کرد آیا برای نصب دات نت 4.5 روی xp یه چنین راه حلی وجود نداره ؟  
با تشکر
بازخوردهای دوره
آشنایی با مدل برنامه نویسی TAP
خیر. بسته‌ی async آن برای دات نت 4.5 کامپایل شده و از اسمبلی‌های دات نت 4.5 استفاده می‌کند. علت هم این‌جا است که متدهای async مربوط به ADO.NET با دات نت 4.5 معرفی شدند و زیر ساخت async مربوط به EF را تشکیل می‌دهند.
اشتراک‌ها
پشتیبانی توکار NET Framework 4.7.1. از NET Standard 2.0.

هرچند NET Standard 2.0.  توسط دات نت 4.6.1 پشتیبانی می‌شود، اما به همراه تمام فایل‌های مورد نیاز آن نیست. به همین جهت حجم توزیع برنامه‌های دات نت 4.6.1 که از کتابخانه‌های NET Standard 2.0. استفاده می‌کنند، بالا خواهد رفت. این مشکل با دات نت 4.7.1 وجود نداشته و تمام کتابخانه‌های جانبی مورد نیاز، جزئی از فریم ورک است.

پشتیبانی توکار NET Framework 4.7.1. از NET Standard 2.0.
مطالب
آشنایی با فرمت OPML

OPML یا Outline Processor Markup Language اساسا فایلی است مبتنی بر XML که امروزه بیشتر جهت توزیع لینک‌های تغذیه خبری سایت‌ها (RSS/Atom و امثال آن) مورد استفاده قرار می‌گیرد.
به بیانی ساده‌تر، بجای این‌که بگویند ما به این 100 وبلاگ علاقمند هستیم و لینک تک تک آنها را به شما ارائه بدهند، یک فایل OPML استاندارد از آن‌ها درست کرده و در اختیار شما قرار می‌دهند. به این صورت با چند کلیک ساده، این فایل در نرم افزار فیدخوان شما import شده و آدرس‌ها بلافاصله قابل استفاده خواهند بود.
نمونه‌ای از این فرمت:
<?xml version="1.0" encoding="UTF-8"?>
<opml version="1.0">
  <head>
      <title>Subscriptions in Google Reader</title>
  </head>
  <body>
      <outline title="Programming">
          <outline
               text="Vahid's Blog"
               title="Vahid's Blog"
               type="atom"
               xmlUrl="http://feeds.feedburner.com/vahidnasiri"
               htmlUrl="https://www.dntips.ir/"/>
چند نمونه فایل OPML مرتبط با برنامه نویسی را از سایت‌های مختلف جمع آوری کرده‌ام که آنها را از این آدرس می‌توانید دریافت کنید.

نحوه استفاده از آنها در Google reader
بعد از ورود به قسمت تنظیمات Google reader ، با استفاده از قسمت import/export می‌توان یک فایل OPML را به آن معرفی کرد (شکل زیر):



و یا با استفاده از برنامه باکیفیت و رایگان FeedDemon و قسمت import feeds آن می‌توان یک فایل OPML را به برنامه وارد کرد. البته این‌جا امکانات بیشتری را نسبت به Google reader دراختیار شما قرار می‌دهد و می‌توانید از لیست دریافتی، موارد مورد نظر را انتخاب کنید و نه تمامی آنها را.




اگر علاقمند بودید که این فایل‌ها را در برنامه‌های دات نت خود import کنید، کتابخانه سورس باز Argotic Syndication Framework این امکان را در اختیار شما قرار می‌دهد.


به روز رسانی
- «از کدام فیدخوان تحت وب استفاده می‌کنید؟»  
- «به روز رسانی فایل OPML وبلاگ‌های IT ایرانی؛ شهریور 94»  
نظرات اشتراک‌ها
بررسی وضعیت فعلی پروژه Roslyn
- فرض کنید الان نیاز دارید یک زیبا ساز کدهای سی‌شارپ را تهیه کنید. منظور این است که به صورت خودکار indentation اضافه کند؛ پارامترهای یک متد را در فواصل مناسب قرار دهد و امثال آن. برای اینکار باید یک parser تمام عیار سی‌شارپ داشته باشید که نوشتن آن کار ساده‌ای نیست.
- فرض کنید می‌خواهید کارهایی را که Resharper در مورد آنالیز کدها انجام می‌دهد، مثلا تشخیص کد مرده در یک متد را خودتان پیاده سازی کنید. اینکار بدون دسترسی به زیر ساخت‌های یک کامپایلر واقعی غیرممکن است و تیم Resharper تا الان مهم‌ترین کاری که انجام دادند، تهیه این زیرساخت قابل دسترسی با کدهای دات نت بوده.
- انجام کارهای AOP در دات نت ساده‌تر خواهد شد. یکی از مواردی که بحث هست در مورد آینده زبان‌های دات نتی، meta programming هست. Roslyn زیرساخت افزودن این امکانات خواهد بود در آینده.
- الان دنیایی از اطلاعات و امکانات داخل کامپایلر native سی‌شارپ دفن شده که کسی به آن دسترسی ندارد و حداکثر این است که مسیر یک سری فایل cs را به آن بدهید و یک خروجی کامپایل شده از آن بگیرید. حیف این امکانات نیست؟! پروژه Roslyn، امکان دسترسی به تمام اجزای یک کامپایلر واقعی را توسط یک سری API عمومی، برای برنامه نویس‌های دات نت میسر می‌کند.
نظرات مطالب
PHP سریعتر از ASP.NET! افسانه یا واقعیت؟
فناوری-زبان PHP بسیار محترم است و بسیار قابل توصیه اما برای آن زمانی که در رقابت با ASP کلاسیک بود و پدیده ای به نام دات نت ظهور نکرده بود حال آنکه پدیده یاد شده در زمان حال به پختگی و پیشرفت چشمگیری دست یافته است.
دنیای دات نت و مباحث مربوط به آن گسترده‌تر و پیچیده‌تر از آن است که برای توجیه استفاده از دات نت سرعت مقایسه شود. ده‌ها ویژگی منحصر به دات نت وجود دارد که برای انتخاب فناوری سمت سرور مجالی برای تفکر درباره سرعت باقی نمی‌گذارد و آنان که اهل تفکر باشند را جذب خود می‌کند و نه گمراهان (کسانی که یا تعصب دارند یا خسته‌تر از آن هستند که دنیای جدیدی را تجربه نمایند.)
در مورد سرعت کافی است نکات ساده ای که چند دقیقه بیشتر زمان نمی‌برند رعایت شود تا وب سایت‌های دات نتی چندین برابر سریعتر عمل کنند.
فراموش نکنید دنیای دات نت تا حد بیشتری با اصول مهندسی نرم افزار گره خورده است و باب میل همگان نیست.
عموماً سرویس دهنده بر حسب فناوری انتخاب می‌شود و نه برعکس! در مقالاتی که مقایسه انجام می‌دهند صحبت از رایگان بودن لینوکس و آپاچی و ... چندان ضرورتی ندارد.
بسیاری از آن‌ها که Open Source بودن PHP را با آب و تاب و به عنوان برتری مطرح می‌کردند هرگز در عمر خود به کدهای سورس آن نگاهی نکرده اند. البته اگر بداند از کجا باید دانلود کنند. توصیه می‌کنم در مورد رویکرد و سیاست‌های چند سال اخیر مایکروسافت در رابطه با Open Source تحقیق بیشتری صورت گیرد.
مثال هایی از سایت‌های موفق و یا تعداد سایت‌ها در یک فناوری هرگز دلیلی برای انتخاب فناوری نیست. ضمناً زمان ظهور این دو فناوری یکسان نبوده است که تعداد وب سایت‌ها معیار مقایسه باشد.
فناوری-زبان PHP هنوز وجود دارد. هنوز قدرت خود را دارد. و هنوز هر کجا به هر دلیلی امکان استفاده از دات نت نبود، با کمال افتخار و خوشحالی از این که چند سال عمری که برای آن گذاشته ام هدر نرفته است به آن باز می‌گردم و آن را مورد استفاده قرار می‌دهم.
مسیرراه‌ها
آزمون واحد در دات نت
آشنایی با آزمایش واحد (unit testing) در دات نت قسمت اول
آشنایی با آزمایش واحد (unit testing) در دات نت قسمت دوم
آشنایی با آزمایش واحد (unit testing) در دات نت قسمت سوم
آشنایی با آزمایش واحد (unit testing) در دات نت قسمت چهارم
آشنایی با آزمایش واحد (unit testing) در دات نت قسمت پنجم
آشنایی با آزمایش واحد (unit testing) در دات نت قسمت ششم

آشنایی با mocking frameworks - قسمت اول
آشنایی با mocking frameworks - قسمت دوم

چگونه کد قابل تست بنویسیم - قسمت اول
چگونه کد قابل تست بنویسیم - قسمت دوم

Test Driven Development

Microsoft Test Manager 

نوشتن آزمون‌های واحد به کمک کتابخانه‌ی Moq  

دیگر مقالات
نظرات نظرسنجی‌ها
برای توسعه برنامه‌های مبتنی بر NET Core. از چه محیطی استفاده می‌کنید؟
قطعا یک محیط عالی برای نوشتن برنامه‌های دات نتی فعلا در حال حاضر خود ویژوال استودیو هست چون از هر نظر که بررسی بشه فول اپشنه و چیزی رو کم نداره البته جاهایی کم کاری کردن ولی خب به چشم نمیاد و خیلی ریزه مشکلاتش و نسبت به نرم افزارهای دیگه سرتره 
مطالب
آشنایی با M.A.F - قسمت اول

در طی چند مقاله قصد بررسی نحوه‌ی تولید برنامه‌های توسعه پذیر (extensible) را با استفاده از plug-ins و یا add-ins داریم.

افزونه‌ها عموما در سه گروه قرار می‌گیرند:
الف) افزونه، سرویسی را به هاست ارائه می‌دهد. برای مثال یک میل سرور نیاز به افزونه‌هایی برای ویروس یابی یا فیلتر کردن هرزنامه‌ها دارد؛ یا یک برنامه پردازش متنی نیاز به افزونه‌ای جهت بررسی غلط‌های املایی می‌تواند داشته باشد و یا یک مرورگر وب می‌تواند با کمک افزونه‌ها قابلیت‌های پیش فرض خود را به شدت توسعه و افزایش دهد (نمونه‌ی بارز آن فایرکس است که عمده‌ترین دلیل اقبال عمومی به آن سهولت توسعه پذیری آن می‌باشد).
ب) در گروه دوم، هاست، رفتار مشخصی را ارائه داده و سپس افزونه بر اساس آن، نحوه‌ی عملکرد هاست را مشخص می‌کند. در این حالت هاست است که سرویسی را به افزونه ارائه می‌دهد. نمونه‌ی بازر آن افزونه‌های آفیس هستند که امکان اتوماسیون فرآیندهای مختلف آن‌را میسر می‌سازند. به این صورت امکان توسعه‌ی یک برنامه به شکلی که در طراحی اولیه آن اصلا انتظار آن نمی‌رفته وجود خواهد داشت. همچنین در اینجا نیازی به داشتن سورس کد برنامه‌ی اصلی نیز نمی‌باشد.
ج) گروه سوم افزونه‌ها تنها از هاست جهت نمایش خود استفاده کرده و عملا استفاده‌ی خاصی از هاست ندارد. برای مثال نوار ابزاری که خود را به windows explorer متصل می‌کند و تنها از آن جهت نمایش خود بهره می‌جوید.


در حال حاضر حداقل دو فریم ورک عمده جهت انجام این‌کار و تولید افزونه‌ها برای دات نت فریم ورک مهیا است:
الف) managed addin framework یا MAF
ب) managed extensibility framework یا MEF

فضای نام جدیدی به دات نت فریم ورک سه و نیم به نام System.AddIn اضافه شده است که به آن Managed AddIn Framework یا MAF نیز اطلاق می‌شود. از این فریم ورک در VSTO (تولید افزونه برای مجموعه‌ی آفیس) توسط خود مایکروسافت استفاده شده است.

فریم ورک توسعه‌ی افزونه‌های مدیریت شده در دات نت فریم ورک سه و نیم، مزایای زیر را در اختیار ما خواهد گذاشت:
- امکانات load و unload افزونه‌های تولید شده
- امکان تغییر افزونه‌ها در زمان اجرای برنامه اصلی بدون نیاز به بستن آن
- ارائه‌ی محیطی ایزوله با ترسیم مرزی بین افزونه و برنامه اصلی
- مدیریت طول عمر افزونه
- مدیریت سازگاری با نگارش‌های قبلی و یا بعدی یک افزونه
- امکانات به اشتراک گذاری افزونه‌ها با برنامه‌های دیگر
- تنظیمات امنیتی و مشخص سازی سطح دسترسی افزونه‌ها
و ...

یک راه حل مبتنی بر MAF می‌تواند شامل 7 پروژه باشد (که به روابط تعریف شده در آن pipeline هم گفته می‌شود):

Host : همان برنامه‌ی اصلی است که توسط یک سری افزونه، توسعه یافته است.
Host View : بیانگر انتظارات هاست از افزونه‌ها است. به عبارت دیگر افزونه‌ها باید موارد لیست شده در این پروژه را پیاده سازی کنند.
Host Side Adapter : پل ارتباطی Host View و پروژه‌ی Contract است.
Contract: اینترفیسی است که کار برقراری ارتباط بین Host و افزونه‌ها را برعهده دارد.
Add-In Side Adapter : پل ارتباطی بین Add-In View و Contract است.
Add-In View :‌ حاوی متدها و اشیایی است که جهت برقراری ارتباط با هاست از آن‌ها استفاده می‌شود.
Add-In : اسمبلی است که توسط هاست جهت توسعه‌ی قابلیت‌های خود بارگذاری می‌شود (به آن Add-On ، Extension ، Plug-In و Snap-In هم گفته می‌شود).

هدف از این جدا سازی‌ها ارائه‌ی راه حل loosely-coupledایی است که امکان ایزوله سازی، اعمال شرایط امنیتی ویژه و همچنین کنترل نگارش‌های مختلف را تسهیل می‌بخشد و این امر با استفاده از interface های معرفی شده میسر گردیده است. این pipeline از قسمت‌های ذیل تشکیل می‌شود:



قرار داد یا Contract
برای تولید یک افزونه نیاز است تا بین هاست و افزونه قراردادی بسته شود. با توجه به استفاده از MAF ، روش تعریف این قرار داد برای مثال در یک افزونه‌ی مترجم به صورت زیر باید باشد:

[AddInContract]
public interface ITranslator : IContract
{
string Translate(string input);
}

استفاده از ویژگی AddInContract و پیاده سازی اینترفیس IContract جزو مراحل کاری استفاده از MAF است. MAF هنگام تولید پویای pipeline ذکر شده به دنبال ویژگی AddInContract می‌گردد. این موارد در فضای نام System.AddIn.Pipeline تعریف شده‌اند.

دیدگاه‌ها یا Views
دیدگاه‌ها کدهایی هستند که کار تعامل مستقیم بین افزونه و هاست را بر عهده دارند. هاست یا افزونه هر کدام می‌توانند دیدگاه خود را نسبت به قرار داد بسته شده داشته باشند. این موارد نیز همانند قرار داد در اسمبلی‌های مجزایی نگهداری می‌شوند.

دیدگاه هاست نسبت به قرار داد:
public abstract class TranslatorHostView
{
public abstract string Translate(string input);
}
دیدگاه افزونه نسبت به قرار داد:
[AddInBase]
public abstract class TranslatorHostView
{
public abstract string Translate(string input);
}

هر دو کلاس فوق بر اساس قرار موجود بنا می‌شوند اما وابسته به آن نیستند. به همین جهت به صورت کلاس‌هایی abstract تعریف شده‌اند. در سمت افزونه، کلاس تعریف شده دیدگاه آن با کلاس دیدگاه سمت هاست تقریبا یکسان می‌باشد؛ اما با ویژگی AddInBase تعریف شده در فضای نام System.AddIn.Pipeline مزین گردیده است.


وفق دهنده‌ها یا Adapters
آخرین قسمت pipeline ، وفق دهنده‌ها هستند که کار آن‌ها اتصال قرار داد به دیدگاه‌ها است و توسط آن مدیریت طول عمر افزونه و همچنین تبدیل اطلاعات بین قسمت‌های مختلف انجام می‌شود. شاید در نگاه اول وجود آن‌ها زائد به نظر برسد اما این جدا سازی کدها سبب تولید افزونه‌هایی خواهد شد که به نگارش هاست و برنامه اصلی وابسته نبوده و بر عکس (version tolerance). به دو کلاس زیر دقت نمائید:

کلاس زیر با ویژگی [HostAdapter] تعریف شده در فضای نام System.AddIn.Pipeline، مزین شده است و کار آن اتصال HostView به Contract می‌باشد. برای این منظور TranslatorHostView ایی را که پیشتر معرفی کردیم باید پیاده سازی نماید. علاوه بر این با ایجاد وهله‌ای از کلاس ContractHandle ، کار مدیریت طول عمر افزونه را نیز می‌توان انجام داد.

[HostAdapter]
public class TranslatorHostViewToContract : TranslatorHostView
{
ITranslator _contract;
ContractHandle _lifetime;

public TranslatorHostViewToContract(ITranslator contract)
{
_contract = contract;
_lifetime = new ContractHandle(contract);
}

public override string Translate (string inp)
{
return _contract.Translate(inp);
}
}
کلاس سمت افزونه نیز بسیار شبیه قسمت قبل است و کار آن اتصال AddInView به Contract می‌باشد که با پیاده سازی ContractBase و Itranslator صورت خواهد گرفت. همچنین این کلاس به ویژگی AddInAdapter مزین گردیده است.

[AddInAdapter]
public class TranslatorAddInViewToContract : ContractBase, ITranslator
{
TranslatorAddInView _view;

public TranslatorAddInViewToContract(TranslatorView view)
{
_view = view;
}

public string Translate(string inp)
{
return _view.Translate(inp);
}
}

قسمت عمده‌ای از این کدها تکراری است. جهت سهولت تولید این کلاس‌ها و پروژه‌های مرتبط، تیم مربوطه برنامه‌ای را به نام pipeline builder ارائه داده است که از آدرس زیر قابل دریافت است:


این برنامه با دریافت اسمبلی مربوط بهcontract ، کار ساخت خودکار کلاس‌های adapters و views را انجام خواهد داد.

ایجاد افزونه
پس از ساخت قسمت‌های مختلف pipeline ، اکنون می‌توان افزونه را ایجاد نمود. هر افزونه باید add-in view را پیاده سازی کرده و با ویژگی AddIn مزین شود. برای مثال:

[AddIn("GoogleTranslator", Description="Universal translator",
Version="1.0.0.0", Publisher="YourName")]
public class GoogleAddIn : TranslatorAddInView
{
public string Translate(string input)
{
...
}
}

ادامه دارد ....

مطالب
نگاشت JSON به کلاس‌های معادل آن

یکی از مواردی که عموما در برنامه نویسی با آن سر و کار داریم، parse اطلاعات با فرمت‌های مختلف است. از CSV تا XML تا ... JSON .
در مورد کار با XML در دات نت فریم ورک، فضاهای نام مرتبط زیادی وجود دارند؛ برای مثال System.Xml.Linq و System.Xml . همچنین یک روش دیگر هم برای کار با اطلاعات XML ایی در دات نت وجود دارد. می‌شود کلاس معادل یک فایل XML را تولید و سپس اطلاعات آن‌را به این کلاس نگاشت کرد. اطلاعات بیشتر : (^). این برنامه کار خود مایکروسافت است.
در مورد JSON از دات نت سه و نیم به بعد کارهایی صورت گرفته مانند : (^). اما آنچنان دلچسب نیست. جهت رفع این خلاء کتابخانه‌ی سورس باز و بسیار کاملی در این زمینه به نام JSON.NET تهیه شده که از این آدرس قابل دریافت است: (^)
و خبر خوب اینکه امکان تهیه کلاس‌های معادل اطلاعات JSON ایی هم مدتی‌است توسط برنامه نویس‌های مستقل تهیه شده است. یا می‌توان از امکانات توکار دات نت استفاده کرد یا از کتابخانه‌‌هایی مانند JSON.NET یا از هیچکدام! می‌توان یک راست کل اطلاعات JSON ایی دریافتی را به یک یا چند کلاس معادل آن نگاشت کرد:
  • و یا یک ابزار آنلاین مشابه: json2csharp