نظرات مطالب
یکی کردن اسمبلی‌های یک پروژه‌ی WPF
منظورم یک پروژه WinForms بود، نه WPF. تمامی اسمبلی‌های لازم به صورت CopyLocal هستند. بنده فقط بند ب را انجام دادم، یعنی فقط فایل CsProj را ویرایش کردم. (اگر باید الف-ج کامل انجام شوند، برای WinForms قسمت الف چگونه خواهد بود؟)
تا پیش از این از Smart Assembly برای merge استفاده می‌کردم. ولی متاسفانه این نرم‌افزار توانایی ادغام همه‌ی اسمبلی‌ها به خصوص اسمبلی‌های Third party company را ندارد.
نظرات مطالب
اعتبارسنجی مبتنی بر JWT در ASP.NET Core 2.0 بدون استفاده از سیستم Identity
مطابق جدول زیر، فقط اسمبلی مرتبط با متد الحاقی AddJwtBearer دارای بسته‌ی نیوگت 3x است و مابقی دیگر به صورت مجزایی تولید نمی‌شوند و جزئی از framework reference هستند .
 آخرین نگارش نیوگت موجود
 اسمبلی مرتبط
متد الحاقی
2.2.0  Microsoft.AspNetCore.Authorization.Policy, Version=3.1.0.0  ()AddAuthorization
2.2.0  Microsoft.AspNetCore.Authentication, Version=3.1.0.0  ()AddAuthentication
3.1.3  Microsoft.AspNetCore.Authentication.JwtBearer, Version=3.1.2.0  ()AddJwtBearer
 بنابراین نیاز به تنظیم target-framework و همچنین framework-reference هست:
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <FrameworkReference Include="Microsoft.AspNetCore.App" />
  </ItemGroup>
</Project>
مطالب
آشنایی با CLR: قسمت نوزدهم
در فصل دوم کتاب تا به الان یاد گرفتیم چگونه ماژول‌ها را کامپایل کنیم و چگونه آن‌ها را در یک اسمبلی قرار دهیم. حال وقت آن فرا رسیده است که با بسته بندی کردن (Package) و انتشار آن (Deploy) به طوری که کاربران بتوانند برنامه را اجرا کنند آشنا شویم.

نصب برنامه از طریق فروشگاه ویندوز
در فروشگاه ویندوز Windows Store Apps قوانین سخت و شدیدی برای بسته بندی کردن اسمبلی‌ها وجود دارد. ویژوال استودیو تمام اسمبلی‌های مورد نیاز برنامه را در یک فایل با پسوند appx قرار داده و آن را به سمت فروشگاه آپلود می‌کند. هر کاربری که این فایل appx را نصب کند، همه‌ی اسمبلی‌هایی را که در دایرکتوری مربوطه قرار گرفته است، توسط CLR بار شده و آیکن برنامه هم در صفحه‌ی start ویندوز قرار می‌گیرد و اگر دیگر کاربران همان سیستم هم این فایل appx را نصب کنند، از آنجا که قبلا روی سیستم موجود هست، تنها آیکن برنامه به صفحه‌ی start اضافه می‌گردد و برای حذف هم تنها آیکن برنامه از روی این صفحه حذف می‌شود؛ مگر اینکه تنها کاربری باشد که این برنامه را نصب کرده‌است که در آن صورت کلا همه‌ی اسمبلی‌های آن از روی سیستم حذف می‌شود.
در صورتیکه کاربرهای مختلف نسخه‌های مختلفی از همان برنامه را روی سیستم نصب کنند، برای اسمبلی‌ها هر کدام یک دایرکتوری ایجاد شده و به ازای نسخه‌ی نصب شده آن کاربر، یکی از این دایرکتوری‌ها مورد استفاده قرار می‌گیرند. کاربران مختلف می‌توانند روی سیستم به طور همزمان از نسخه‌های مختلف برنامه استفاده کنند.

روش‌های پکیج گذاری
برای برنامه‌های دسکتاپ که ربطی به فروشگاه ندارند و بین ایرانیان طرفدار زیادی دارد، نیازی به استفاده از هیچ روش خاصی نیست و یک کپی معمولی هم کفایت می‌کند. همه‌ی فایل‌های مثل اسمبلی، باید در یک دایرکتوری قرار گرفته و به روش کپی کردن آن را انتقال داد. یا برای بسته بندی از یک فایل batch کمک گرفت و آن را روی سیستم نصب کرد و نیازی به هیچ تغییری در رجیستری نیست. برای حذف برنامه هم، حذف معمولی دایرکتوری مربوطه کفایت می‌کند.
البته گزینه‌های دیگری هم برای پکیج کردن این نوع برنامه‌ها وجود دارند:
یکی از روش‌های پکیج کردن فایل‌ها به صورت cab هست که عموما برای سناریوهای اینترنتی و فشرده سازی و کاهش زمان دانلود به کار می‌رود.
روش دوم استفاده از پکیج MSI است که توسط سرویس نصب مایکروسافت Microsoft Installer Service یا MSIExec.exe انجام می‌گیرد. فایل‌های MSI به اسمبلی‌ها اجازه می‌دهند که بر اساس زمان تقاضای CLR برای بارگیری اولیه نصب شوند. البته این ویژگی جدیدی نیست و برای فایل‌های exe یا dll مدیریت نشده هم به کار می‌رود.

استفاده از نصاب سازها
بهتر هست که برای انتشار برنامه از برنامه‌های نصاب سازی استفاده کنید که با واسطی جذاب‌تر به نصب پرداخته و امکاناتی از قبیل shotrcut‌ها، حذف و بازیابی و نصب و .. را هم به کاربر می‌دهند.
نصاب سازهای متفاوتی وجود دارند که در زیر به تعدادی از آنها اشاره می‌کنیم:
Install Shield (+ ) : این برنامه نسخه‌های متفاوتی را با قیمت‌های متفاوتی، عرضه می‌کند و در این زمینه، جزء بهترین‌ها نام برده می‌شود. حتی ویژگی‌های مخصوصی هم برای ویژوال استودیو دارد. شرکت سازنده، برنامه‌ی دیگری را هم اخیر تحت نام Install Anywhere عرضه کرده است که اجازه می‌دهد از روی یک برنامه برای پلتفرم‌های مختلف setup بسازد.

NSIS : این برنامه هم در زمینه‌ی ساخت setup محبوبیت زیادی دارد. این برنامه به صورت متن باز منتشر شده و رایگان است. امکانات این برنامه ساده است و برای راه اندازی سریع یک setup و اجرای راحت آن توسط کاربر، کاملا کاربردی است.

Tarma Installmate : این نرم افزار نسبت به InstallShield ساده‌تر و کم حجم‌تر است. حداقل برای برنامه‌های عادی امکانات مناسبی دارد.

DeployMaster : یک برنامه‌ی دیگر با امکانات حرفه‌ای جهت انشار برنامه‌های دسکتاپ، که از ویندوز 98 تا 8.1 را در حال حاضر پشتیبانی می‌کند.

QSetup Installation Suite : یک برنامه‌ی نصب حرفه‌ای که فایل نهایی آن می‌تواند به دو فرمت exe یا MSI باشد و قابلیت‌هایی چون پشتیبانی از زبان فارسی، ورود لایسنس، سریال نرم افزار و ... را نیز پشتیبانی می‌کند.

Inno Setup : این برنامه هم امکانات خوبی را برای ساخت یک نصاب ساز دارد و همچنین از زبان پاسکال جهت اسکریپت نویسی جهت توسعه امکانات بهره می‌برد.

Visual Patch : وب سایت پی سی دانلود این برنامه را اینگونه توضیح می‌دهد:
نرم افزار Visual Patch یک ابزار توسعه یافته‌ی نرم افزاری برای ساخت پچ و آپدیت برنامه‌ها می‌باشد. این سازنده پچ باینری، استفاده از فشرده سازی داده DeltaMAX برای سریع‌تر کردن توسعه‌ی نرم افزار، یکپارچگی با نصب نرم افزار و ابزار‌های مدیریت پچ از فروشندگانی نظیر Installshield, Lumension, Patchlink, Shavlik, Indigo Rose و ...، را به طور برجسته نمایان ساخته است.
با استفاده از این ابزار پچ کردن برنامه‌ها که برای توسعه دهندگان نرم افزار و برنامه نویسان طراحی شده است، توزیع نرم افزار و سیستم گسترش پچ بهبود می‌یابد. Visual Patch الگوریتم‌های فشرده سازی و state-of- the-art binary differencing را نمایان می‌سازد و این کمک می‌کند که شما به کوچکتر شدن و بهتر شدن پچ‌های نرم افزار اطمینان داشته باشید.  
و ...

انتشار توسط ویژوال استودیو
ویژوال استودیو هم امکانات خوبی برای انتشار در بخش Properties پروژه، برگه‌ی publish ارائه می‌کند و فایل MSI نتیجه را به سمت وب سرور، FTP Server یا روی دیسک ارسال میکند. یکی از خصوصیات خوب این روش این است که میتواند پیش نیازهایی مانند فریم ورک دات نت یا sql server Express را به سیستم اضافه کنید؛ در نهایت با مزیت آپدیت و نصب تک کلیکی، کاربر، برنامه را بر روی سیستم نصب کند.

اسمبلی‌های انتشاریافته اختصاصی
در روش‌هایی که ذکر کردیم، از آنجا که اسمبلی‌ها در همان شاخه یا دایرکتوری برنامه قرار گرفته‌اند و نمی‌توان آن‌ها را با برنامه‌های دیگر به اشتراک گذاشت (مگر اینکه برنامه دیگری را هم در همان دایرکتوری قرار داد) به این روش Privately Deployed Assemblies می‌گویند. این روش برگ برنده بزرگی برای برنامه نویسان، کاربران و مدیران سیستم‌ها محسوب می‌شود. زیرا که جابجایی آنها راحت بوده و CLR در همانجا اسمبلی‌ها را در حافظه بار کرده و اجرا می‌کند. در این نوع برنامه‌ها عملیات نصب/جابجایی/ حذف به راحتی صورتی میگرد و نیازی به تنظیمات خارجی مانند رجیستری ندارد. یکی از خصوصیات مهمی که دارد این هست که جداول متادیتا به اسمبلی اشاره می‌کنند که برنامه بر پایه آن ساخته شده و با آن تست شده است؛ نه با اسمبلی موجود دیگر در سیستم که شاید نام نوع مورد استفاده آن یا اسمبلی آن به طور تصادفی با آن یکی است.
در مقالات آتی در مورد اشتراک گذاری اسمبلی‌ها بین چند برنامه مفصل‌تر صحبت خواهیم کرد.

نظرات مطالب
EF Code First #1
DbContext نیاز به ارجاعی به اسمبلی EF دارد که باید به این class libraryهای دیگر هم اضافه شود.
مطالب
تغییرات Encoding در NET Core.
فرض کنید قصد دارید یک قطعه کد پیشین تغییر Encoding از ویندوز عربی، به یونیکد را که در Full .NET Framework به خوبی کار می‌کند، در NET Core. اجرا کنید:
var path = @"D:\file1.srt";
var data = System.IO.File.ReadAllText(path, Encoding.GetEncoding("windows-1256"));
System.IO.File.WriteAllText(path, data, Encoding.UTF8);
به محض اجرای این قطعه کد، استثنای ذیل را دریافت خواهید کرد:
 System.ArgumentException: 'windows-1256' is not a supported encoding name. For information on defining a custom encoding, see
the documentation for the Encoding.RegisterProvider method.
Parameter name: name
عنوان می‌کند که encoding مخصوص windows-1256 را نمی‌شناسد. این تغییری است که در نحوه‌ی ثبت سایر Encodings غیریونیکد صورت گرفته‌است.


معرفی اسمبلی System.Text.Encoding.CodePages

تمام Encodings غیریونیکد به اسمبلی ویژه‌ای به نام System.Text.Encoding.CodePages منتقل گردیده‌اند و به صورت پیش‌فرض هم هیچکدام از آن‌ها در سیستم معرفی و ثبت نشده‌اند.
به همین منظور ابتدا باید وابستگی ذیل را به فایل csproj برنامه اضافه کرد:
<ItemGroup>
    <PackageReference Include="System.Text.Encoding.CodePages" Version="4.3.0" />
</ItemGroup>


معرفی کل مجموعه‌ی Encodings غیریونیکد به برنامه

پس از بازیابی این وابستگی با اجرای دستور dotnet restore، اکنون می‌توان کل مجموعه‌ی Encodings موجود در آن‌را به سیستم معرفی نمود:
    public class MyClass 
    {
        static MyClass()
        {
            Encoding.RegisterProvider(CodePagesEncodingProvider.Instance);
        }
این‌کار نیز باید یکبار در طول عمر برنامه انجام شود. به همین جهت می‌توان این معرفی را در آغاز برنامه انجام داد و یا می‌توان آن‌را مانند مثال فوق به یک سازنده‌ی استاتیک منتقل نمود. در این حالت بدون هیچگونه تغییری در کدهای پیشین، امکان اجرای آن‌ها وجود خواهد داشت.


امکان دسترسی به تنها یک Encoding ویژه

قطعه کد عنوان شده، تمام Encoding موجود در اسمبلی System.Text.Encoding.CodePages را به صورت یکجا به سیستم معرفی می‌کند. مزیت آن عدم نیاز به تغییری در کدهای پیشین است؛ اما اگر تنها نیاز به یکی از آن‌ها را دارید، می‌توان به صورت ذیل عمل کرد و دیگر نیازی به ذکر Encoding.RegisterProvider نیست:
 var enc1256 = CodePagesEncodingProvider.Instance.GetEncoding(1256);
نظرات مطالب
معرفی Xamarin و مزیت‌های استفاده از آن
با سلام خدمت شما
linked سعی می‌کنه کدهای بلا استفاده رو از تو اسمبلی‌های رفرنس خورده حذف کنه، مشابه با pro guard در اندروید
اگر کدی به صورت داینامیک فراخونی شده باشه به اشتباه حذف می‌شه، در اون صورت می‌شه نام یک اسمبلی یا یک کلاس یا یک متد رو داد که حذف نشه، که این واقعا کم پیش میآد 
اینکار یعنی link باید حتما انجام بشه 
نظرات مطالب
طراحی افزونه پذیر با ASP.NET MVC 4.x/5.x - قسمت اول
- پیشنیازهای مطلب را یکبار مطالعه کنید؛ خصوصا مورد «اصول طراحی یک سیستم افزونه پذیر به کمک StructureMap» که در آن  scanner.AddAllTypesOf ذکر شده‌است. در آنجا IPlugin ثبت شده‌است؛ شما Profile یا هر نوع دیگری را که نیاز است به آن اضافه کنید.
-روش دوم: در مثالی که ذکر شده، تک اسمبلی جاری بررسی می‌شود. برای یافتن تمام اسمبلی‌های بارگذاری شده‌ی در برنامه (منجمله پلاگین‌ها) از متد ()AppDomain.CurrentDomain.GetAssemblies استفاده کنید.
نظرات مطالب
بررسی بهبودهای پروسه‌ی Build در دات‌نت 8

یک نکته‌ی تکمیلی: چگونه تاریخ Build را به اسمبلی برنامه اضافه کنیم؟

شاید علاقمند باشید که بجای نمایش شماره نگارش برنامه، تاریخ Build آن‌را در قسمتی خاص، نمایش دهید. برای اینکار می‌توان یک ویژگی جدید را به صورت زیر به اسمبلی برنامه اضافه کرد:

[AttributeUsage(AttributeTargets.Assembly)]
public sealed class BuildDateAttribute : Attribute
{
    public BuildDateAttribute(string buildDateTime) => BuildDateTime = buildDateTime;

    public string BuildDateTime { get; }
}

تا در زمان کامپایل برنامه، فایل obj\Debug\net8.0\DntSite.Web.AssemblyInfo.cs را به این صورت تکمیل کند:

using System;
using System.Reflection;

[assembly: DNTCommon.Web.Core.BuildDateAttribute("1403.05.28.15.17")]
[assembly: System.Reflection.AssemblyCompanyAttribute("DntSite.Web")]
[assembly: System.Reflection.AssemblyConfigurationAttribute("Debug")]

مقدار دهی این این ویژگی جدید، در زمان Build و توسط تنظیمات زیر در فایل csproj. برنامه انجام می‌شود:

<Project>
  <ItemGroup>
        <AssemblyAttribute Include="DNTCommon.Web.Core.BuildDateAttribute">
            <_Parameter1>$([System.DateTime]::Now.ToString("yyyy.MM.dd.HH.mm"))</_Parameter1>
        </AssemblyAttribute>
  </ItemGroup>

با استفاده از AssemblyAttribute می‌توان پارامترهای دلخواهی را به ویژگی Include شده، ارسال کرد؛ برای مثال، تاریخ جاری سیستم را. اگر تعداد پارامترهای سازنده بیشتر بود، می‌توان Parameter2_ و Parameter3_ و ... را هم تنظیم کرد.

همین اندازه تنظیم برای اضافه شدن خودکار این ویژگی جدید به اسمبلی نهایی برنامه کافی است (و همانطور که عنوان شد، محل درج خودکار اولیه‌ی آن، در فایل AssemblyInfo.cs پوشه‌ی obj برنامه‌است). برای خواندن و نمایش آن هم می‌توان به صورت زیر عمل کرد:

public static class BuildDateAttributeExtensions
{
    public static string? GetBuildDateTime(this Assembly? assembly) =>
        assembly?.GetCustomAttribute<BuildDateAttribute>()?.BuildDateTime ??
        assembly?.GetName().Version?.ToString();
}

برای نمونه می‌توان اطلاعات BuildDateAttribute اسمبلی جاری را به صورت زیر استخراج کرد:

private static string? GetVersionInfo() => Assembly.GetExecutingAssembly().GetBuildDateTime();