نظرات مطالب
تفاوت انواع var و dynamic
بله اینها صحیح، ولی statically typed dynamic عبارتی است که Anders Hejlsberg هنگام صحبت در مورد آینده C# در  PDC09 به کاربرد.
The Future of C#
 
The dynamic keyword acts as a static type declaration in the C# type system. This way C# got the dynamic features and at the same time remained a statically typed language. 

http://msdn.microsoft.com/en-us/magazine/gg598922.aspx 
در واقع کلمه کلیدی dynamic به کامپایلر می‌فهماند که compile-time checking  را غیر فعال کن! تا در زمان اجرا به نوع متغییر رسیدگی شود.

شاید اگر بگوییم dynamic نوعی static است که مزایای انواع dynamic را در بر می‌گیرد بهتر باشد.

خواندن این مقاله هم خالی از لطف نیست:
مطالب
آموزش #F
در نظر سنجی که قبلا توسط دوستان درباره میزان آشنایی و استفاده از زبان‌های مختلف برنامه نویسی در تولید پروژه‌های نرم افزاری انجام شده بود (^) تعداد رای زبان #F سه رای بود(یعنی کمتر از یک درصد). یکی از دلایلی که #F کمتر از سایر زبان‌ها مورد توجه است (البته تا این زمان) نبود منبع یا کتاب فارسی در زمینه یادگیری و هم چنین عدم شناخت از امکانات و قدرت این زبان است. در نتیجه تصمیم گرفتم در طی دو یا چند دوره به آموزش برنامه نویسی این زبان بپردازم. دوره اول که  از قسمت دوره‌ها (^ )در این سایت در دسترس عموم  قرار دارد سطوح مقدماتی و متوسط را پوشش می‌دهد (سرفصل‌های این دوره در قسمت آموزش #F ذکر شده است). به دلیل حجم گسترده مطالب امکان ارایه تمام مفاهیم و روش‌ها در طی یک دوره امکان پذیر نبود در نتیجه تصمیم بر آن شد که با توجه به اولویت‌های آموزشی این مطالب طبقه بندی شوند و طی دو یا چند دوره به دوستان عزیز ارائه شوند.
دوره ای که هم اکنون در دسترس است صرفا جهت آشنایی دوستان با نوع کدنویسی و مفاهیم برنامه نویسی این زبان تهیه شده است اما دوره پیشرفته این زبان که بعدا در طی چند فصل، آموزش داده خواهد شد دارای سرفصل‌های زیر خواهد بود:
  • استفاده از #F در پروژه‌های تولید شده با زبان #C و در محیط  Visual Studio.Net 
  • استفاده از EntityFramework در زبان #F
  • تولید و توسعه پروژهای Windows Application با زبان #F
  • تولید و توسعه پروژهای WPF با زبان #F
  • تولید و توسعه پروژه‌های تحت Silverlight با زبان #F
  • و...

موفق باشید.

اشتراک‌ها
بررسی NET Standard.

Description

There has been a lot of talk lately about .NET Standard, both in the community and on Channel 9. But there is also still confusion about it. In this episode, Kathleen Dollard clears up some of this confusion. She and Robert chat about why .NET Standard was created, as well as how and when you should take advantage of it.  

بررسی NET Standard.
اشتراک‌ها
استفاده از فایل‌های JSON بجای XML برای بومی سازی برنامه‌های ASP.NET Core

Elemental.JsonResource

Json Resource file support in C# projects.

This provides an alternative to using resx files to defined resources in C# projects. The benefits over resx are:

  • human readable file format (try writing resx xml from scratch without documentation)
  • generated C# code doesn't get included in project/source control
  • Doesn't require modifying the .csproj (adding a single resx file will add ~12 lines to your csproj file)
  • Doesn't require Visual Studio to function. (resx files don't work in VS Code for example) 
استفاده از فایل‌های JSON بجای XML برای بومی سازی برنامه‌های ASP.NET Core
مطالب
sp_send_dbmail و ارسال ایمیل فارسی

نکته‌ی کوچکی در مورد ارسال ایمیل فارسی توسط رویه ذخیره شده سیستمی sp_send_dbmail اس کیوال سرور وجود دارد که شبیه به insert داده‌های فارسی در دیتابیسی است که پس از ثبت، به صورت ؟؟؟ ذخیره می‌شوند. (این مورد با تنظیم collation تقریبا قابل حل است)
اگر هنگام ثبت، collation عربی یا فارسی (در اس کیوال سرور 2008) انتخاب شود، مشکلی در ثبت نخواهد بود.
اگر به collation اهمیت نمی‌دهید باید اس کیوال سرور را مجبور کرد که داده را یونیکد ذخیره کند و اینکار با اضافه کردن یک N به ابتدای رشته صورت می‌گیرد و همچنین انتخاب نوع داده‌های n دار مانند nvarchar و امثال آن (n در اینجا به معنای national و اجبار آن می‌باشد):

Insert into tblTest(f1,f2) values(1,N'متن فارسی')
دقیقا همین نکته هم درباره‌ی ارسال ایمیل از طریق اس کیوال سرور صادق است. اگر N به ابتدای رشته اضافه نشود، رشته ارسالی را با فرمت ANSI ارسال می‌کند و داده‌های یونیکد متن تخریب خواهند شد؛ مثلا چیزی شبیه به حالت زیر:

<div align="center"><table border="1" width="95%" dir="rtl" cellspacing="0" cellpadding="0" style="font-family: Tahoma; font-size: 8pt" bordercolor="#660066"><tr><td bgcolor="#FFF9FF"><blockquote><p align="justify"><br>????? ????? ?<br>???? ???? ? ????? ?????? ??? ?? ????? ????? ?????. ???? ??? ???? ???? ????? ????? ????? ????? ????? ??? ??? ???? ???? ?????? ? ???? ?? ????? ???? ???? ??? ????? ??????.<br>???? ??? ????? ???? ?? ?????? ???? ????? ?????? ????? ? ?? ???? ???????? ????? ???? ???? ???? ?????? ???? ???? ??? ?? ????? ????.</blockquote></td></tr></table></div>
این مشکل به صورت زیر قابل حل است:

DECLARE @msg NVARCHAR(max)
SET @msg=N'متن فارسی'
برای ردگیری وضعیت ایمیل‌های ارسالی هم می‌توان از کوئری‌های زیر استفاده نمود:

SELECT * from sysmail_allitems
SELECT * from sysmail_faileditems
SELECT * from sysmail_event_log

اشتراک‌ها
هزینه واقعی توسعه UI در دات نت
The purpose of these experiments is to show that everything has a cost
If you use C#/XAML the cost is performance but you gain a vast amount of capability out of the box
If you use C++/DirectX the cost is increased effort and development time but you gain the best performance and so forth  
هزینه واقعی توسعه UI در دات نت
اشتراک‌ها
Visual Studio 2017 version 15.7.3 منتشر شد

These are the customer-reported issues addressed in 15.7.3:

Visual Studio 2017 version 15.7.3  منتشر شد
نظرات مطالب
آشنایی با الگوی طراحی Decorator
در استفاده از الگوی دکوراتور روش بهتر بهره گیری از آن بصورت سری است و نه ایجاد شیء جدید برای تایپ جدید.
مثلا:
Cake c = new Cake();

c = new Type1(c);
c = new SubType(c); //SubType derived from  Cake (e.g. CakeComponent like Cream)  

//or: c = new Type1 (new SubType(c));  

Console.WriteLine(c.Bake() + ", " + c.GetPrice());
مطالب
آشنایی با CLR: قسمت بیستم
در قسمت قبلی با نحوه انتشار برنامه‌ها آشنا شدیم. در این قسمت نحوه پیکربندی یا تغییر پیکربندی برنامه را مشخص می‌کنیم.
کاربر یا مدیر سیستم بهتر از هر کسی می‌تواند جنبه‌های‌های مختلف اجرای برنامه را مشخص کند. به عنوان نمونه ممکن است مدیر سیستم بخواهد فایل‌های یک برنامه را سمت هارد دیسک سیستم کاربر انتقال دهد یا اطلاعات مانیفست یک اسمبلی را رونویسی کند و مباحث نسخه بندی که در آینده در مورد آن صحبت می‌کنیم.
با ارائه یک فایل پیکربندی در شاخه برنامه می‌توان به مدیر سسیتم  اجازه داد تا کنترل بیشتر بر روی برنامه داشته باشد. ناشر برنامه می‌تواند این فایل را همراه دیگر فایل‌های برنامه پکیج کند تا در شاخه برنامه نصب شود تا بعدا مدیر یا کاربر سیستم بتوانند آن را تغییر و ویرایش کنند. CLR هم محتوای این فایل را تفسیر کرده و قوانین بارگیری اسمبلی‌ها و ... را تغییر می‌دهد. این فایل پیکربندی می‌تواند به صورت XML هم ارائه شود. مزیت قرار دادن یک فایل جداگانه نسبت به رجیستری این مزیت را دارد که هم قابل جابجایی و پشتیبانی گیری است و هم اینکه تغییر آن ساده‌تر است.
البته در آینده بیشتر در مورد این فایل صحبت می‌کنیم ولی در حال حاضر بهتر است اندکی طعم آن را بچشیم. فرض را بر این می‌گذاریم که ناشر می‌خواهد فایل‌های اسمبلی MultiFileLibrary را در دایرکتوری جداگانه‌ای قرار دهد و چیزی شبیه به ساختار زیر را در نظر دارد:
AppDir directory (contains the application’s assembly files)
Program.exe
Program.exe.config (discussed below)


AuxFiles subdirectory (contains MultiFileLibrary’s assembly files)
MultiFileLibrary.dll
FUT.netmodule
RUT.netmodule

حال با تنظیم بالا به دلیل اینکه CLR انتظار دارد این اسمبلی را در دایرکتوری برنامه بیابد و با این جابجایی قادر به انجام این کار نیست، استثنای زیر را صادر می‌کند:
System.IO.FileNotFoundException
برای حل این مشکل، ناشر یک فایل XML را ایجاد کرده و در مسیر دایرکتوری برنامه قرار می‌دهد. این فایل باید همنام اسمبلی اصلی برنامه با پسوند config. باشد. به عنوان مثال، نام فایل می‌شود: Program.exe.config و فایل پیکربندی هم چیزی شبیه فایل زیر می‌شود:
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas­microsoft­com:asm.v1">
<probing privatePath="AuxFiles" />
</assemblyBinding>
</runtime>
</configuration>
حالا هر موقع CLR در جست و جوی یک اسمبلی باشد که نتواند آن را در دایرکتوری مربوطه بیابد مسیر Auxfiles را هم بررسی خواهد کرد. با قرار دادن کارکتر « , » هم می‌توان برای خصوصیت PrivatePath، دایرکتوری‌های زیادتری را معرفی کرد. البته مسیردهی این خصوصیت باید به طور نسبی باشد نه مطلق یا اینکه یک مسیر نسبی خارج از دایرکتوری برنامه. ایده اصلی اینکار این است که برنامه کنترل بیشتری روی دایرکتوری خود و دایرکتوری‌های زیرمجموعه داشته باشد نه خارج از آن.

نحوه عملکرد اسکن CLR برای بارگزاری اسمبلی ها
موقعی که CLR قصد بارگزاری اسمبلی‌های خنثی را دارد، شاخه‌های زیر را به طور خودکار اسکن خواهد نمود ( مسیرهای FirstPrivatePath و SecondPrivatePath توسط فایل پیکربندی مشخص شده است)
AppDir\AsmName.dll
AppDir\AsmName\AsmName.dll
AppDir\firstPrivatePath\AsmName.dll
AppDir\firstPrivatePath\AsmName\AsmName.dll
AppDir\secondPrivatePath\AsmName.dll
AppDir\secondPrivatePath\AsmName\AsmName.dll
...

این نکته ضروری است که اگر اسمبلی شما در یک دایرکتوری همنام خودش (در مثال ما MultiFileLibrary) قرار بگیرد، نیازی نیست این مسیر را در فایل پیکربندی ذکر کنید؛ زیرا CLR در صورت نیافتن دایرکتوری با این نام را اسکن خواهد نمود. بعد از آن اگر به هر نحوی CLR نتواند اسمبلی را در هیچ کدام از دایرکتوری‌های گفته شده بیابد، با همان قوانین گفته شده اینبار به دنبال فایلی با پسوند exe خواهد بود و اگر باز هم جست و جوی آن نتیجه‌ای را در بر نداشته باشد، استثنای زیر را صادر می‌کند:
 FileNotFoundException
برای اسمبلی‌های ماهواره‌ای همان قوانین بالا دنبال می‌شود؛ با این تفاوت که انتظار می‌رود اسمبلی داخل یک زیر دایرکتوری با تگ‌های RFC1766 مطابقت داشته باشد. به عنوان مثال اگر اسمبلی با فرهنگ و منطقه En-US مشخص شده باشد، دایرکتوری‌های زیر اسکن خواهند شد:
C:\AppDir\en­US\AsmName.dll
C:\AppDir\en­US\AsmName\AsmName.dll
C:\AppDir\firstPrivatePath\en­US\AsmName.dll
C:\AppDir\firstPrivatePath\en­US\AsmName\AsmName.dll
C:\AppDir\secondPrivatePath\en­US\AsmName.dll
C:\AppDir\secondPrivatePath\en­US\AsmName\AsmName.dll
C:\AppDir\en­US\AsmName.exe
C:\AppDir\en­US\AsmName\AsmName.exe
C:\AppDir\firstPrivatePath\en­US\AsmName.exe
C:\AppDir\firstPrivatePath\en­US\AsmName\AsmName.exe
C:\AppDir\secondPrivatePath\en­US\AsmName.exe
C:\AppDir\secondPrivatePath\en­US\AsmName\AsmName.exe
C:\AppDir\en\AsmName.dll
C:\AppDir\en\AsmName\AsmName.dll
C:\AppDir\firstPrivatePath\en\AsmName.dll
C:\AppDir\firstPrivatePath\en\AsmName\AsmName.dll
C:\AppDir\secondPrivatePath\en\AsmName.dll
C:\AppDir\secondPrivatePath\en\AsmName\AsmName.dll
C:\AppDir\en\AsmName.exe
C:\AppDir\en\AsmName\AsmName.exe
C:\AppDir\firstPrivatePath\en\AsmName.exe
C:\AppDir\firstPrivatePath\en\AsmName\AsmName.exe
C:\AppDir\secondPrivatePath\en\AsmName.exe
C:\AppDir\secondPrivatePath\en\AsmName\AsmName.exe

نحوه اسکن کردن CLR میتواند به ما بگوید که عمل اسکن می‌تواند گاهی اوقات با زمان زیادی روبرو شود (به خصوص که قابلیت اسکن روی شبکه را هم دارد). برای محدود کردن ناحیه یا نواحی اسکن می‌توانید یک یا چند المان culture را در فایل پیکربندی مشخص کنید. همچنین مایکروسافت ابزاری به نام FUSLogVw.exe را ارائه داده است که می‌تواند نواحی اسکن را در حین اجرای برنامه به ما گزارش دهد.

نام و محل فایل پیکربندی بسته به نوع برنامه می‌تواند متغیر باشد:
برای فایل‌های اجرایی EXE فایل پیکربندی باید در شاخه فایل اجرایی باشد و باید نام فایل پیکربندی همانند فایل exe بوده و یک پسوند config. را به آن اضافه کرد.

برای برنامه‌های وب فرم، فایل web.config موجود است که در ریشه شاخه مجازی وب اپلیکیشن قرار میگیرد و هر زیر دایرکتوری هم می‌تواند یک web.config جداگانه داشته باشد که میتواند از web.config ریشه هم تنظمیاتش را ارث بری کند. برای نمونه آدرس زیر را در نظر بگیرد:
https://www.dntips.ir/newsarchive

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

فصل دوم «نحوه ساخت و توزیع اسمبلی ها» از بخش اول «اصول اولیه CLR» پایان یافت. فصل بعدی در مورد اسمبلی‌های اشتراکی است که بعد از آماده شدن این فصل، قسمت‌های بعدی در دسترس عزیزان قرار خواهد گرفت.