مطالب
اصول طراحی شی گرا SOLID - #بخش پنجم اصل DIP

اصل 5)  D – DIP– Dependency Inversion principle 
مقایسه با دنیای واقعی:
همان مثال کامپیوتر را دوباره در نظر بگیرید.این کامپیوتر دارای قطعات مختلفی مانند RAM ، هارد دیسک، CD ROM و ... است که هر کدام به صورت مستقل به مادربرد متصل شده اند. این به این معنی است که اگر قسمتی از کار بیفتد میتوان آن را با یک قطعه‌ی جدید به آسانی تعویض کرد . حالا فقط تصور کنید که تمامی قطعات شدیداً به یکدیگر متصل شده اند آنوقت دیگر نمیتوانستیم قطعه ای را از مادربرد برداریم و به همین خاطر اگر مثلا RAM از کار بیفتد ، یاید یک مادربرد جدید خریداری کنید که برای شما گران تمام می‌شود.
به مثال زیر توجه کنید :
public class CustomerBAL
{
    public void Insert(Customer c)
    {
        try
        {
            //Insert logic
        }
        catch (Exception e)
        {
            FileLogger f = new FileLogger();
            f.LogError(e);
        }
    }
}

public class FileLogger
{
    public void LogError(Exception e)
    {
        //Log Error in a physical file
    }
}
در کد بالا کلاسCustomerBAL مستقیما به کلاس FileLogger وابسته است که استثناء‌های رخ داده را بر روی یک فایل فیزیکی لاگ میکند. حالا فرض کنید که چند روز بعد مدیریت تصمیم میگیرد که از این به بعد استثناء‌ها بر روی یک Event  Viewer لاگ شوند. اکنون چه میکنید؟ با تغییر کدها ممکن است با خطاهای زیادی روبرو شوید(درصورت تعداد بالای کلاسهایی که از کلاس FileLogger استفاده میکنند و فقط تعداد محدودی از آنها نیاز دارند که بر روی Event Viewer لاگ کنند.)
DIP  به ما میگوید : " ماژول‌های سطح بالا نباید به ماژولهای سطح پایین وابسته باشند، هر دو باید به انتزاعات وابسته باشند. انتزاعات نباید وابسته به جزئیات باشند، بلکه جزئیات باید وابسته به انتزاعات باشند. ".
در طراحی ساخت یافته، ماژولهای سطح بالا به ماژولهای سطح پایین وابسته بودند. این مسئله دو مشکل ایجاد می‌کرد:
1-  ماژول‌های سطح بالا (سیاست گذار) به ماژول‌های سطح پایین (مجری) وابسته هستند. در نتیجه هر تغییری در ماژول‌های سطح پایین ممکن است باعث اشکال در ماژول‌های سطح بالا گردد.
2-  استفاده مجدد از ماژول‌های سطح بالا در جاهای دیگر مشکل است، زیرا وابستگی مستقیم به ماژول‌های سطح پایین دارند.
راه حل با توجه به اصل DIP :
public interface ILogger
{
    void LogError(Exception e);
}

public class FileLogger:ILogger
{
    public void LogError(Exception e)
    {
        //Log Error in a physical file
    }
}
public class EventViewerLogger : ILogger
{
    public void LogError(Exception e)
    {
        //Log Error in a Event Viewer
    }
}
public class CustomerBAL
{
    private ILogger _objLogger;
    public CustomerBAL(ILogger objLogger)
    {
        _objLogger = objLogger;
    }

    public void Insert(Customer c)
    {
        try
        {
            //Insert logic
        }
        catch (Exception e)
        {            
            _objLogger.LogError(e);
        }
    }
}
در اینجا وابستگی‌های کلاس CustomerBAL از طریق سازنده آن در اختیارش قرار گرفته است. یک اینترفیس ILogger تعریف شده‌است به همراه دو پیاده سازی مختلف از آن مانند FileLogger و EventViewerLogger. 
یکی از انواع فراخوانی آن نیز می‌تواند به شکل زیر باشد:
var customerBAL = new CustomerBAL (new EventViewerLogger());
customerBAL.LogError();
اطلاعات بیشتر در دوره آموزشی "بررسی مفاهیم معکوس سازی وابستگی‌ها و ابزارهای مرتبط با آن  ".       
مطالب
آموزش VC++ از مقدماتی تا پیشرفته
بحثی که بنده قصد آموزش آن را دارم آموزش  ++ C  در IDE  مایکروسافت  visual studio  می‌باشد . آموزش از پروژه‌های Win32 Console Application  شروع شده و قسمت پیشرفته آموزش در پروژه‌های Win32 Project ادامه می‌یابد .
...

اولین پروژه

معمولا برای شروع از تاریخچه و توضیحات دیگر استفاده میکنند اما روش آموزشی که در پیش خواهیم گرفت با انجام پروژه‌های عملی بوده و هر جا که نیاز به توضیح باشد ، بیان میکنیم ...

ایجاد اولین پروژه  Win32 Console Application

ویژوال استادیو را اجرا نمایید و از گزینه  File -> New -> Project و سپس طبق عکس زیر پروژه Win32 Console Application را انتخاب نمایید ، دقت کنید که زبان انتخاب شده ++Visual C باشد.

در این مرحله میتوانید محل ذخیره شده پروژه را در قسمت Location  تنظیم نمایید و از قسمت  Name  میتوانید نام دلخواه را وارد کنید در حالت پیش فرض اگر اولین پروژه Win32 Console  در مسیر تعین شده‌ی قسمت  Location  باشد ، نام  ConsoleApplication1  قرار گرفته است . پس از تنظیمات Ok کنید .

در این مرحله Next  را بزنید .

در این مرحله در قسمت Additional options  تیک Empty project را بزنید ، همانند عکس فوق تنظیمات را انجام دهید .

پس از انجام مراحل فوق پروژه بصورت شکل زیر ظاهر میشود .

برای کد نویسی روی نام پروژه که در اینجا ConsoleApplication1 می‌باشد ، راست کلیک میکنیم و گزینه Add و سپس New Item  را انتخاب میکنیم .

طبق عکس زیر فایل با پسوند cpp  را انتخاب و Add  میکنیم .

فایلی که اکنون به پروژه اضافه کردیم خالی و با نام پیش فرض Source.cpp  می‌باشد ، دستورات زیر را در آن تایپ کنید .حال پروژه به شکل زیر خواهد بود .

#include<iostream>

int  main()
{
   std::cout<<"Hello world ...\n";
   return 0;
}

برای اجرای پروژه کلید F5 را فشار دهید و اگر میخواهید نتیجه کار را مشاهده کنید کلید Ctrl + F5  را امتحان کنید .

شما اولین پروژه VC++  را اجرا نمودید ( آفرین ) .

اما توضیحات :

خط اول برنامه یک راهنمای پیش پردازنده است ، کاراکتر # که نشان میدهد این خط یک راهنمای پیش پردازنده است و بعد عبارت include  و نام یک فایل کتابخانه ای که بین علامت <> قرار داده شده ،  فایل سرآیند استفاده شده در اینجا  iostream  میباشد . (به فایل‌های کتابخانه ای ، فایلهای سرآیند (Header Files) نیز گفته میشود. ) راهنمای پیش پردازنده خطی است که به کامپایلر اطلاع میدهد در برنامه موجودیتی است که تعریف آن را در فایل سرآیند مذکور جستجو کند . در این برنامه از std::cout  استفاده شده ، که کامپایلر در مورد آن چیزی نمیداند لذا به فایل iostream  مراجعه نموده ، تعریف آن را می‌یابد و آن را اجرا میکند . 

خط 3 :

بخشی از هر برنامه تابع می‌باشد . پرانتزهای واقع پس از  آن  main نشان می‌دهند که main یک بلوک برنامه بنام تابع است. برنامه‌ها می‌توانند حاوی یک یا چندین تابع  باشند، اما main  تابع اصلی برنامه است که وجود آن الزامی میباشد . کلمه کلیدی  int  که در سمت چپ main   قرار گرفته، بر این نکته دلالت دارد که main  یک مقدار صحیح برمی‌گرداند.

خط 5 :

با استفاده از این دستور رشته ای را به خروجی استاندارد که معمولا صفحه نمایش باشد ارسال میکنیم .

خط 6 :

که ;0 return میباشد مقدار برگشتی تابع را مشخص میکند در حقیقت این خط که مقدار 0 را برمیگرادند نشان دهنده اتمام موفقیت آمیز برنامه می‌باشد .

به مرور زمان نسبت به موارد بالا بیشتر و مفصل صحبت خواهیم نمود .

مطالب
3# آموزش سیستم مدیریت کد Git

شاید از دید بسیاری از برنامه‏ نویسان بررسی نحوه عملکرد Git چندان اهمیتی نداشته باشد، زیرا آن‏ها سیستمی کارا برای مدیریت کد‏های خود لازم دارند و نیازی نمی‏‌بینند که به جزئیات رفتار Git توجه کنند؛ به همین دلیل در بسیاری از منابع آموزشی این مفاهیم به این شکل گردآوری نشده است. اما من ترجیح دادم برای مدیریت و استفاده بهتر از Git حتی الامکان مطالب کاربردی را از پشت صحنه عملکرد Git در این بخش قرار دهم.

(Working Tree (Directory: پوشه‏‌ی روتی است که فایل‏های پروژه در آن نگه‏داری می‏‌شود. این پوشه باید حاوی پوشه‌ای به نام git. باشد که محتویات این پوشه، در اصل Repository ما را تشکیل می‏دهند.

اشیا در Git:

برای درک بهتر عملکرد سیستم مدیریت کد Git بهتر است نگاهی به اجزای تشکیل دهنده آن داشته باشیم. به طور کلی Git دارای 4 نوع object است، که هر کدام وظیفه خاصی را به عهده دارند:

1)Tree: شیئ Tree دقیقا مانند دایرکتوری‏‌ها در یک سیستم مدیریت فایل است. در واقع tree‌ها ساختاری درختی را ایجاد می‏‌کنند تا وضیعت فایل‏ها و پوشه‌ها را در Repository حفظ نمایند. هر tree توسط یک کد منحصر به فرد SHA-1 نام گذاری می‌شود.

2)(BLOB(Binary large object: اگر با سیستم‏های مدیریت داده نظیر SQL Server کار کرده باشید قطعا با BLOB آشنایی دارید. BLOB‌ها در واقع چیزی نیستند جز یک مجموعه از بایت‏‏ها که می‏توانند حاوی هر چیزی باشند (نظیر عکس، فایل متنی،  فایلهای اجرایی و...) در Git فایل‏ها به صورت BLOB و به شکل کامل ذخیره می‏‌شوند. همچنین مقدار هش شده محتویات فایل‏ها با استفاده از SHA-1 در خود فایل ذخیره می‏‌شود. به این ترتیب در صورت تغییر در فایل، مقدار هش جدید با مقدار موجود در فایل فرق کرده و Git متوجه می‏‌شود که فایل دچار تغییر شده است. نکته قابل توجه این است که بر خلاف بسیاری از سیستم‏های مدیریت کد، در هر بار تغییر فایل، Git تنها تغییرات را ذخیره نمی‏‌کند بلکه از کل محتوا یک snapshot می‏‌گیرد. شاید به نظر بسیاری تهیه این ‏snapshotهای فراوان باعث زیاد شدن حجم Repository شود، اما Git هوشمندانه تنها فایل‏‌هایی را مجددا ذخیره می‌نماید که مقدار آن‏ها تغییر کرده است. در غیر این صورت یک نشانگر به فایل موجود در snapshot جدید ایجاد می‏کند.

3)Commit: این شئ، یک  snapshot از وضعیت فعلی Working Tree است. در واقع با هر با دستور commit این object ایجاد شده و حداقل حاوی اطلاعات زیر است:

مقدار هش درختی که به آن اشاره می‏کند

نام ثبت کننده دستور commit

توضیحی درباره علت ایجاد commit

خود commit نیز توسط یک کد منحصر به فرد SHA-1 شناخته می‏‌شود.

4)Tag: چون کار کردن با کد‏های هش commit ممکن مشکل باشد، می‌توان از تگ‏ها به عنوان نامی برای commit استفاده نمود. خود تگ می‏‌تواند حاوی توضیحاتی باشد.

آشنایی با (Stage(Index:

هر فایل قبل از آنکه بخواهد در Repository توسط دستور commit ذخیره شود باید ابتدا به Stage آورده شود. در این حالت Git تغیرات فایل را دنبال کرده و سپس می‏‌توان توسط دستور commit فایل را در Repository وارد کرد. بنابراین ذخیره یک فایل در Git دارای سه مرحله است:

Modified : یعنی فایل تغییر کرده اما به stage اضافه نشده است

Staged: فایل تغییر کرده به stage اضافه شده است.

Commited: فایل در Repository ذخیره شده است.

head:

اشاره‏‌گری است که به آخرین شئ commit اشاره می‏‌کند. هر Repository می‏تواند یک head برای هر شاخه‏‏‌ی مختلف داشته باشد؛ اما در هر لحظه تنها یک head به عنوان head جاری شناخته می‏‌شود که معمولا آن را با حروف بزرگ یعنی HEAD مشخص می‏‌کنند.

تا این مرحله شما تقریبا تمامی آنچه که برای شروع کار با Git را لازم دارید آموخته‏‌اید. البته همان‏طور که در ابتدا اشاره کردم این مباحث دارای جزئیات بسیاری است اما تا این اندازه برای کار با Git کفایت می‏‌کند. در صورتیکه به نکات خاصی احتیاج پیدا کنیم، در طول بیان دستورات Git  به آن‏ها اشاره خواهد شد. در قسمت بعد نحوه‏‌ی نصب و پیکره‌بندی Git را بررسی می‏‌کنیم.

مطالب
اضافه کردن پیوست به فایل‌های PDF با استفاده از iTextSharp

فایل PDF موجود عجیب و غریبی است. می‌شود به آن فایل پیوست اضافه کرد. مثلا اگر یک راهنمای آموزشی را با فرمت PDF تهیه می‌کنید، لازم نیست تا فایل‌های مرتبط با آن‌را جداگانه ارائه دهید. می‌شود تمام این‌ها را داخل همان فایل PDF مدفون کرد. روش انجام اینکار به کمک iTextSharp ساده است اما چند نکته را نیز به همراه دارد:

using System.Diagnostics;
using System.IO;
using iTextSharp.text;
using iTextSharp.text.pdf;

namespace PDFAttachment
{
class Program
{
static void Main(string[] args)
{
using (var pdfDoc = new Document(PageSize.A4))
{
var pdfWriter = PdfWriter.GetInstance(pdfDoc, new FileStream("Test.pdf", FileMode.Create));
pdfDoc.Open();

pdfDoc.Add(new Phrase("Test"));

var fs = PdfFileSpecification.FileEmbedded(pdfWriter, @"C:\path\logo.png", "logo.png", null);
pdfWriter.AddFileAttachment("توضیحات",fs);
}

Process.Start("Test.pdf");
}
}
}

در ساده‌ترین حالت ممکن، با استفاده از متد AddFileAttachmen شیء PdfWriter می‌توان پیوستی را به یک فایل PDF در حال تولید اضافه کرد. اگر به فایل نهایی مراجعه کنیم و همچنین قسمت attachments را هم دستی در Adobe reader انتخاب نمائیم، شکل زیر حاصل خواهد شد:


روش متداول بکارگرفته شده دو مشکل را به همراه دارد:
  • قسمت modified مقدار دهی نشده است.
  • پنل مربوط به پیوست‌ها باید دستی باز شود.

نحوه مقدار دهی ستون modified پس از تعریف یک PdfDictionary و قرار دادن PdfName.MODDATE در آن، به صورت زیر است:

using System.Diagnostics;
using System.IO;
using iTextSharp.text;
using iTextSharp.text.pdf;

namespace PDFAttachment
{
class Program
{
static void Main(string[] args)
{
using (var pdfDoc = new Document(PageSize.A4))
{
var pdfWriter = PdfWriter.GetInstance(pdfDoc, new FileStream("Test.pdf", FileMode.Create));
pdfDoc.Open();

pdfDoc.Add(new Phrase("Test"));

var filePath = @"C:\path\logo.png";
var fileInfo = new FileInfo(filePath);
var pdfDictionary = new PdfDictionary();
pdfDictionary.Put(PdfName.MODDATE, new PdfDate(fileInfo.LastWriteTime));
var fs = PdfFileSpecification.FileEmbedded(pdfWriter, filePath, fileInfo.Name, null, true, null, pdfDictionary);
pdfWriter.AddFileAttachment("توضیحات", fs);
}

Process.Start("Test.pdf");
}
}
}

که اینبار خروجی زیر را به همراه دارد:


و برای نمایش خودکار پنل پیوست‌ها در Adobe reader به طوری که کاربر نهایی متوجه وجود این فایل‌های پیوست شده گردد، می‌توان ViewerPreferences شیء pdfWriter را مقدار دهی نمود:

pdfWriter.ViewerPreferences = PdfWriter.PageModeUseAttachments;

در مورد فایل‌های موجود چطور؟ آیا می‌توان به یک فایل PDF از پیش تهیه شده هم فایل پیوست کرد؟
پاسخ: بله. باید از امکانات شیء PdfReader استفاده کرد:

using System.Diagnostics;
using System.IO;
using iTextSharp.text;
using iTextSharp.text.pdf;

namespace PDFAttachment
{
class Program
{
static void Main(string[] args)
{
var reader = new PdfReader("Test.pdf");
using (var stamper = new PdfStamper(reader, new FileStream("newTest.pdf", FileMode.Create)))
{
var filePath = @"C:\path\logo.png";
addAttachment(stamper, filePath, "توضیحات");
stamper.Close();
}

Process.Start("newTest.pdf");
}

private static void addAttachment(PdfStamper stamper, string filePath, string description)
{
var fileInfo = new FileInfo(filePath);
var pdfDictionary = new PdfDictionary();
pdfDictionary.Put(PdfName.MODDATE, new PdfDate(fileInfo.LastWriteTime));
var pdfWriter = stamper.Writer;
var fs = PdfFileSpecification.FileEmbedded(pdfWriter, filePath, fileInfo.Name, null, true, null, pdfDictionary);
stamper.AddFileAttachment(description, fs);
}
}
}

در اینجا به کمک کلاس PdfReader، یک فایل موجود خوانده شده و سپس با استفاده از امکانات کلاس PdfStamper که خاصیت Writer آن همان pdfWriter است می‌توان فایل مورد نظر را به فایل موجود افزود.


مطالب
کمپین ضد IF !

بکارگیری بیش از حد If و خصوصا Switch برخلاف اصول طراحی شیءگرا است؛ تا این حد که یک کمپین ضد IF هم وجود دارد!



البته سایت فوق بیشتر جنبه تبلیغی برای سمینارهای گروه مذکور را دارد تا اینکه جنبه‌ی آموزشی/خود آموزی داشته باشد.

یک مثال کاربردی:
فرض کنید دارید یک سیستم گزارشگیری را طراحی می‌کنید. به جایی می‌رسید که نیاز است با Aggregate functions سروکار داشته باشید؛ مثلا جمع مقادیر یک ستون را نمایش دهید یا معدل امتیازهای نمایش داده شده را محاسبه کنید و امثال آن. طراحی متداول آن به صورت زیر خواهد بود:

using System.Collections.Generic;

using System.Linq;

namespace CircularDependencies
{
public enum AggregateFunc
{
Sum,
Avg
}

public class AggregateFuncCalculator
{
public decimal Calculate(IList<decimal> list, AggregateFunc func)
{
switch (func)
{
case AggregateFunc.Sum:
return getSum(list);
case AggregateFunc.Avg:
return getAvg(list);
default:
return 0m;
}
}

private decimal getAvg(IList<decimal> list)
{
if (list == null || !list.Any()) return 0;
return list.Sum() / list.Count;
}

private decimal getSum(IList<decimal> list)
{
if (list == null || !list.Any()) return 0;
return list.Sum();
}
}
}

در کلاس AggregateFuncCalculator یک متد Calculate داریم که توسط آن قرار است روی list دریافتی یک سری عملیات انجام شود. عملیات پشتیبانی شده هم توسط یک enum معرفی شده؛ برای مثال اینجا فقط جمع و میانگین پشتیبانی می‌شوند.
و مشکل طراحی این کلاس، همان switch است که برخلاف اصول طراحی شیء‌گرا می‌باشد. یکی از اصول طراحی شیءگرا بر این مبنا است که:
یک کلاس باید جهت تغییر، بسته اما جهت توسعه، باز باشد.

یعنی چی؟
داستان طراحی Aggregate functions که فقط به جمع و میانگین خلاصه نمی‌شود. امروز می‌گویند واریانس چطور؟ فردا خواهند گفت حداقل و حداکثر چطور؟ پس فردا ...
به عبارتی این کلاس جهت تغییر بسته نیست و هر روز باید بر اساس نیازهای جدید دستکاری شود.

چکار باید کرد؟
آیا می‌توانید در کلاس AggregateFuncCalculator یک الگوی تکراری را تشخیص دهید؟ الگوی تکراری موجود، محاسبات بر روی یک لیست است. پس می‌شود بر اساس آن یک اینترفیس عمومی را تعریف کرد:

public interface IAggregateFunc

{
decimal Calculate(IList<decimal> list);
}

اکنون هر کدام از پیاده سازی‌های موجود در کلاس AggregateFuncCalculator را به یک کلاس جدا منتقل خواهیم کرد تا یک اصل دیگر طراحی شیءگرا نیز محقق شود:
هر کلاس باید تنها یک کار را انجام دهد.

public class Sum : IAggregateFunc

{
public decimal Calculate(IList<decimal> list)
{
if (list == null || !list.Any()) return 0;
return list.Sum();
}
}

public class Avg : IAggregateFunc
{
public decimal Calculate(IList<decimal> list)
{
if (list == null || !list.Any()) return 0;
return list.Sum() / list.Count;
}
}

تا اینجا 2 هدف مهم حاصل شده است:
- کم کم کلاس AggregateFuncCalculator دارد خلوت می‌شود. قرار است هر کلاس یک کار را بیشتر انجام ندهد.
- برنامه از بسته بودن جهت توسعه هم خارج شده است (یکی دیگر از اصول طراحی شیءگرا). اگر تعاریف توابع محاسباتی را تماما در یک کلاس قرار دهیم صاحب اول و آخر آن کتابخانه خودمان خواهیم بود. این کلاس بسته است جهت تغییر. اما با معرفی IAggregateFunc، من امروز 2 تابع را تعریف کرد‌ه‌ام، شما فردا توابع خاص خودتان را تعریف کنید. باز هم برنامه کار خواهد کرد. نیازی نیست تا من هر روز یک نگارش جدید از کتابخانه را ارائه دهم که در آن فقط یک تابع دیگر اضافه شده است.

اکنون یکی از چندین و چند روش بازنویسی کلاس AggregateFuncCalculator به صورت زیر می‌تواند باشد

public class AggregateFuncCalculator

{
public decimal Calculate(IList<decimal> list, IAggregateFunc func)
{
return func.Calculate(list);
}
}

بله! دیگر سوئیچی در کار نیست. این کلاس تنها یک کار را انجام می‌دهد. همچنین دیگر نیازی به تغییر هم ندارد (محاسبات از آن خارج شده) و باز است جهت توسعه (شما نگارش‌های دلخواه IAggregateFunc دیگر خود را توسعه داده و استفاده کنید).

مطالب
لینک‌های هفته‌ی آخر دی

وبلاگ‌ها ، سایت‌ها و مقالات ایرانی (داخل و خارج از ایران)


Visual Studio


ASP. Net



طراحی و توسعه وب



PHP


اس‌کیوال سرور


سی شارپ


عمومی دات نت


ویندوز


مسایل اجتماعی و انسانی برنامه نویسی


متفرقه


مطالب
Delegate در سی شارپ
یک Delegate نوعی اشاره‌گر است به توابع در سی شارپ که می‌تواند ارجاعی را به یک یا چند تابع بخصوص داشته باشد. منظور از توابع در سی شارپ، متدها هستند. امضای یک Delegate باید با متدی که به آن اشاره می‌کنید یکی باشد.
using System;
using System.Windows.Forms;
 
namespace CSharpDelegates
{
    public delegate void Display(string sMsg);
    public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();
        }
 
        private void Form1_Load(object sender, EventArgs e)
        {
            Display del = new Display(ShowMessage);
            del("This is an example for delegate");
        }
 
        private void ShowMessage(string strMessage)
        {
            MessageBox.Show(strMessage);
        }
 
    }
}
  همانطور که در کد بالا مشاهده می‌کنید، Delegate‌ها بسیار شبیه به کلاس‌ها هستند. می‌توانیم از آنها یک شیء ساخته و نام متدی را که قرار است به آن اشاره کند، از طریق سازنده به آن ارسال کنیم. در کد بالا یک Delegate را با نام Display ساخته‌ایم که به متد ShowMessage اشاره می‌کند. اگر به Delegate و متد ShowMessage دقت کنید خواهید دید که هر دو دارای پارامتر ورودی و امضای یکسانی هستند. ما شیءای به نام Display را از نوع Delegate ساخته‌ایم که متدی به نام ShowMessage را با پارامتر ورودی از نوع string، اجرا می‌کند.
شاید بپرسید که چرا باید از Delegate استفاده کنیم؟ چرا متد ShowMessage را مستقیما اجرا نکنیم؟
خوب، Delegate‌ها برای طراحی فریم ورکهایی با قابلیت استفاده‌ی مجدد از کدهای آنها، بسیار مناسب هستند. بگذارید این مطلب را با یک مثال ساده از کلاس Employee توضیح دهیم.
ویژال استودیو را باز کنید و یک پروژه‌ی Windows Forms Application ساده را با نام CSharpDelegates بسازید. سپس کلاس زیر را به آن اضافه کنید:   
using System.Collections.Generic;
 
namespace CSharpDelegates
{
    public class Employee
    {
        public int EmployeeId { get; set; }
 
        public string Name { get; set; }
 
        public int Experience { get; set; }
 
        public double Salary { get; set; }
 
        public void IncreaseSalary(List<Employee> Employees)
        {
            foreach (Employee emp in Employees)
            {
                if (emp.Salary < 10000)
                {
                    emp.Salary = emp.Salary + emp.Salary * 0.3;
                }
            }
        }
    }
}
در کلاس Employee بالا، تعدادی فیلد و یک متد با نام IncreaseSalary داریم که وظیفه‌ی آن افزایش 30% حقوق کارمندانی است که کمتر از 10000 می‌گیرند. اگر در آینده قصد داشته باشیم که علاوه بر این افزایش حقوق، منطق دیگری را با میزان ترفیع و شایستگی کارمندان نیز لحاظ کنیم، لازم است کدهای متد IncreaseSalary را تغییر دهیم که این کار، یک کار خسته کننده است و شاید ما دوست نداشته باشیم تا کدهای کلاس پایه‌ی Employee را تغییر دهیم. در این نوع سناریوها می‌توان با استفاده از Delegateها، منطق افزایش حقوق و منطق ترفیع و شایستگی کارمندان را از هم جدا کرد. خوب، اولین کار، ویرایش متد IncreaseSalary است:  
using System.Collections.Generic;
 
namespace CSharpDelegates
{
    public delegate bool SalaryIncreaseEligibility(Employee emp);
    public class Employee
    {
        public int EmployeeId { get; set; }
 
        public string Name { get; set; }
 
        public int Experience { get; set; }
 
        public double Salary { get; set; }
 
        public string IncreaseSalary(List<Employee> Employees, SalaryIncreaseEligibility del)
        {
            string sSalIncreasdEmployees = "Salary increased for ";
            foreach (Employee emp in Employees)
            {
                if (del(emp))
                {
                    emp.Salary = emp.Salary + emp.Salary * 0.3;
                    sSalIncreasdEmployees = sSalIncreasdEmployees + emp.Name + " ,";
                }
            }
 
            return sSalIncreasdEmployees;
        }
    }
}
همانطور که در کد بالا قابل مشاهده است، منطق افزایش حقوق بر اساس ترفیع و شایستگی کارمندان را با Delegate ایی به نام SalaryIncreaseEligibility جدا کرده‌ایم. بدین وسیله می‌توانیم منطق شناسایی کردن کارمندان لایق افزایش حقوق را بدون ایجاد تغییری در کلاس Employee سفارشی کنیم. حال بگذارید متد IncreaseSalary از کلاس Employee را با منطق سفارشی خود برای افزایش حقوق کارمندان لایق، با کمک Delegate ایی به نام SalaryIncreaseEligibility اجرا کنیم. 
using System;
using System.Collections.Generic;
using System.Windows.Forms;
 
namespace CSharpDelegates
{
    public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();
        }
 
        private void Form1_Load(object sender, EventArgs e)
        {
            List<Employee> empList = new List<Employee>();
            empList.Add(new Employee() { EmployeeId = 100, Name = "Mark", Salary = 2000, Experience = 3 });
            empList.Add(new Employee() { EmployeeId = 101, Name = "John", Salary = 15000, Experience = 8 });
            empList.Add(new Employee() { EmployeeId = 102, Name = "David", Salary = 4000, Experience = 4 });
            empList.Add(new Employee() { EmployeeId = 103, Name = "Bob", Salary = 50000, Experience = 14 });
            empList.Add(new Employee() { EmployeeId = 104, Name = "Alex", Salary = 9000, Experience = 6 });
 
            SalaryIncreaseEligibility del = new SalaryIncreaseEligibility(SalaryEligibility);
 
            Employee objEmp = new Employee();
            string sMsg = objEmp.IncreaseSalary(empList, del);
 
            MessageBox.Show(sMsg);
        }
 
        private bool SalaryEligibility(Employee emp)
        {
            if (emp.Salary > 10000)
            {
                return true;
            }
            else
            {
                return false;
            }
        }
 
    }
}
در کد بالا ما منطق ترفیع و شایستگی کارمندان را از متد SalaryEligibility جدا کرده‌ایم و این منطق را به کمک Delegate ای به نام SalaryIncreaseEligibility به متد ذکر شده پاس داده‌ایم. در آینده اگر قصد داشته باشیم تا این افزایش حقوق را بر اساس منطق دیگری تعریف کنیم، فقط کافیست که متد SalaryEligibility را تغییر دهیم و دیگر لازم نیست تغییری در کلاس Employee ایجاد کنیم.
مطالب
آشنایی با 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» پایان یافت. فصل بعدی در مورد اسمبلی‌های اشتراکی است که بعد از آماده شدن این فصل، قسمت‌های بعدی در دسترس عزیزان قرار خواهد گرفت.
 
مطالب
آشنایی با CLR: قسمت ششم
در مقاله قبلی مبحث کامپایلر JIT را آغاز کردیم. در این قسمت قصد داریم مبحث کارآیی CLR و مباحث دیباگینگ را پیش بکشیم.
از آنجا که یک کد مدیریت نشده، مبحث کارهای JIT را ندارد، ولی CLR مجبور است وقتی را برای آن بگذارد، به نظر می‌رسد ما با یک نقص کوچک در کارآیی روبرو هستیم. گفتیم که جیت کدها را در حافظه‌ی پویا ذخیره می‌کند. به همین خاطر با terminate شدن یا خاتمه دادن به برنامه، این کدها از بین می‌روند یا اینکه اگر دو نمونه از برنامه را اجرا کنیم، هر کدام جداگانه کد را تولید می‌کنند و هر کدام برای خودشان حافظه‌ای بر خواهند داشت و اگر مقایسه‌ای با کدهای مدیریت نشده داشته باشید، در مورد مصرف حافظه یک مشکل ایجاد می‌کند. همچنین JIT در حین تبدیل به کدهای بومی یک بهینه سازی روی کد هم انجام میدهد که این بهینه سازی وقتی را به خود اختصاص می‌دهد ولی همین بهینه سازی کد موجب کارآیی بهتر برنامه می‌گردد.
در زبان سی شارپ دو سوئیچ وجود دارند که بر بهینه سازی کد تاثیر گذار هستند؛ سوئیچ‌های debug و optimize. در جدول زیر تاثیر هر یک از سوئیچ‌ها را بر کیفیت کد IL و JIT در تبدیل به کد بومی را نشان میدهد.

موقعیکه از دستور -optimize استفاده می‌شود، کد IL تولید شده شامل تعداد زیادی از دستورات بدون دستورالعمل No Operation یا به اختصار NOP و پرش‌های شاخه‌ای به خط کد بعدی می‌باشد. این دستور العمل‌ها ما را قادر میسازند تا ویژگی edit & Continue را برای دیباگ کردن و یک سری دستورالعمل‌ها را برای کدنویسی راحت‌تر برای دیباگ کردن و ایجاد break point‌ها داشته باشیم.

موقعی که کد IL بهینه شده تولید شود، این خصوصیات اضافه حذف خواهند شد و دنبال کردن خط به خط کد، کار سختی می‌شود. ولی در عوض فایل نهایی exe یا dll، کوچکتر خواهد شد. بهینه سازی IL توسط JIT حذف خواهد شد و برای کسانی که دوست دارند کدهای IL را تحلیل و آنالیز کنند، خواندنش ساده‌تر و آسان‌تر خواهد بود.

نکته‌ی بعدی اینکه موقعیکه شما از سوئیچ (/debug(+/full/pdbonly استفاده می‌کنید، یک فایل PDB  یا Program Database ایجاد می‌شود. این فایل به دیباگرها کمک می‌کند تا متغیرهای محلی را شناسایی و به کدهای IL متصل شوند. کلمه‌ی full بدین معنی است که JIT می‌تواند دستورات بومی را ردیابی کند تا مبداء آن کد را پیدا کند. سبب می‌شود که ویژوال استودیو به یک دیباگر متصل شده تا در حین اجرای پروسه، آن را دیباگ کند. در صورتی که این سوئیچ را استفاده نکنید، به طور پیش فرض پروسه اجرا و مصرف حافظه کمتر می‌شود. اگر شما پروسه‌ای را اجرا کنید که دیباگر به آن متصل شود، به طور اجباری JIT مجبور به انجام عملیات ردیابی خواهد شد؛ مگر اینکه گزینه‌ی suppress jit  optimization on module load را غیرفعال کرده باشید.
موقعیکه در ویژوال استودیو دو حالت دیباگ و ریلیز را انتخاب می‌کنید، در واقع تنظیمات زیر را اجرا می‌کنید:

//debug

/optimize­ 
/debug:full

//=======================

//Release

/optimize+
/debug:pdbonly
احتمالا موارد بالا به شما می‌گویند که یک سیستم مبتنی بر CLR مشکلات زیادی دارد که یکی از آن‌ها، زمان‌بر بودن انجام عملیات فرآیند پردازش است و دیگری مصرف زیاد حافظه و عدم اشترک حافظه که در مورد کامپایل جیت به آن اشاره کردیم. ولی در بند بعدی قصد داریم نظرتان را عوض کنم.

اگر خیلی شک دارید که واقعا یک برنامه‌ی CLR کارآیی یک برنامه را پایین می‌آورد، بهتر هست به بررسی کارآیی چند برنامه غیر آزمایشی noTrial که حتی خود مایکروسافت آن برنامه‌ها را ایجاد کرده است بپردازید و آن‌ها را با یک برنامه‌ی unmanaged مقایسه کنید. قطعا باعث تعجب شما خواهد شد. این نکته دلایل زیادی دارد که در زیر تعدادی از آن‌ها را بررسی می‌کنیم.
اینکه CLR در محیط اجرا قصد کمپایل دارد، باعث آشنایی کامپایلر با محیط اجرا می‌گردد. از این رو تصمیماتی را که می‌گیرد، می‌تواند به کارآیی یک برنامه کمک کند. در صورتیکه یک برنامه‌ی unmanaged که قبلا کمپایل شده و با محیط‌های متفاوتی که روی آن‌ها اجرا میشود، هیچ آشنایی ندارد و نمیتواند از آن محیط‌ها حداکثر بهره‌وری لازم را به عمل آورد.
برای آشنایی با این ویژگی‌ها توجه شما را به نکات ذیل جلب می‌کنم:

یک.  JIT می‌تواند با نوع پردازنده آشنا شود که آیا این پردازنده از نسل پنتیوم 4 است یا نسل Core i. به همین علت می‌تواند از این مزیت استفاده کرده و دستورات اختصاصی آن‌ها را به کار گیرد، تا برنامه با performance بالاتری اجرا گردد. در صورتی که unmanaged باید حتما دستورات را در پایین‌ترین سطح ممکن و عمومی اجرا کند؛ در صورتیکه شاید یک دستور اختصاصی در یک سی پی یو خاص، در یک عملیات موجب 4 برابر، اجرای سریعتر شود.

دو.  JIT میتواند بررسی هایی را که برابر false هستند، تشخیص دهد. برای فهم بهتر، کد زیر را در نظر بگیرید:
if (numberOfCPUs > 1) {
...
}

کد بالا در صورتیکه پردازنده تک هسته‌ای باشد یک کد بلا استفاده است که جیت باید وقتی را برای کامپایل آن اختصاص دهد؛ در صورتیکه JIT باهوش‌تر از این حرفاست و در کدی که تولید می‌کند، این دستورات حذف خواهند شد و باعث کوچکتر شدن کد و اجرای سریعتر می‌گردد.

سه. مورد بعدی که هنوز پیاده سازی نشده، ولی احتمال اجرای آن در آینده است، این است که یک کد می‌تواند جهت تصحیح بعضی موارد چون مسائل مربوط به دیباگ کردن و مرتب سازی‌های مجدد، عمل کامپایل را مجددا برای یک کد اعمال نماید.
دلایل بالا تنها قسمت کوچکی است که به ما اثبات می‌کند که چرا CLR می‌تواند کارآیی بهتری را نسبت به زبان‌های unmanaged امروزی داشته باشد. همچنین قول‌هایی از سازندگان برای بهبود کیفیت هر چه بیشتر این سیستم‌ها به گوش می‌رسد.

کارآیی بالاتر
اگر برنامه‌ای توسط شما بررسی شد و دیدید که نتایج مورد نیاز در مورد performance را نشان نمی‌دهد، می‌توانید از ابزار کمکی که مایکروسافت در بسته‌های فریمورک دات نت قرار داده است استفاده کنید. نام این ابزار Ngen.exe است و وظیفه‌ی آن این است که وقتی برنامه بر روی یک سیستم برای اولین مرتبه اجرا می‌گردد، کد همه‌ی اسمبلی‌ها را تبدیل کرده و آن‌ها روی دیسک ذخیره می‌کند. بدین ترتیب در دفعات بعدی اجرا، JIT بررسی می‌کند که آیا کد کامپایل شده‌ی اسمبلی از قبل موجود است یا خیر. در صورت وجود، عملیات کامپایل به کد بومی لغو شده و از کد ذخیره شده استفاده خواهد کرد.
نکته‌ای که باید در حین استفاده از این ابزار به آن دقت کنید این است که کد در محیط‌های واقعی اجرا چندان بهینه نیست. بعدا در مورد این ابزار به تفصیل صحبت می‌کنیم.

system.runtime.profileoptimization
کلاس بالا سبب می‌شود که CLR در یک فایل ثبت کند که چه متدهایی در حین اجرای برنامه کمپایل شوند تا در آینده در حین آغاز اجرای برنامه کامپایلر JIT بتواند همزمان این متدها را در ترد دیگری کامپایل کند. اگر برنامه‌ی شما روی یک پردازنده‌ی چند هسته‌ای اجرا می‌شود، در نتیجه اجرای سریعتری خواهید داشت. به این دلیل که چندین متد به طور همزمان در حال کمپایل شدن هستند و همزمان با آماده سازی برنامه برای اجرا اتفاق می‌افتد؛ به جای اینکه عمل کمپایل همزمان با تعامل کاربر با برنامه باشد.

مطالب
آشنایی با ساختار IIS قسمت پنجم
در مطالب قبلی در مورد ماژولار بودن IIS زیاد صحبت کردیم، ولی اجازه بدهید این مورد را به صورت کاربردی‌تر و موشکافانه‌تر بررسی کنیم. برای اینکه به مشکلی در طول این سری از مطالب برنخورید، IIS را به صورت کامل یعنی full feature نصب نمایید. از بخش control panel>programs & features>Turn Windows features on or off اقدام نمایید و هرچه زیر مجموعه Internet information service هست را برگزینید. در صورتی که از نسخه‌های ویندوز سرور 2008 استفاده می‌کنید از طریق server manager>roles>web server اقدام نمایید.
برای نصب یک ماژول باید دو مرحله را انجام داد:
  1. نصب ماژول
  2. فعال سازی ماژول
نکته ای که در مورد ماژول‌های native وجود دارد این هست که این ماژول‌ها دسترسی بدون محدودیتی به منابع سروری دارند و از این رو حتما باید این نکته را دقت کنید که ماژول native شما از یک منبع مورد اعتماد دریافت شده باشد.

نصب یک native module
برای نصب می‌توانید یکی از سه راه زیر را استفاده کنید:
  1. ویرایش دستی فایل کانفیگ و از نسخه IIS7.5 به بعد هم می‌توانید از configuration editor هم استفاده کنید.
  2. استفاده از محیط گرافیکی IIS
  3. استفاده از خط فرمان با دستور Appcmd
مزیت روش دستی این هست که شما دقیقا می‌دانید در پشت صحنه چه اتفاقی می‌افتد و نتیجه هر کدام از این سه روش، اضافه شدن یک مدخل ورودی به تگ <globalmodules> است. برای اعمال تغییرات، مسیر زیر را بروید:
%windir%\system32\inetsrv\config\applicationhost.config
کسی که نیاز به دسترسی به این مسیر و انجام تغییرات دارد باید در بالاترین سطح مدیریتی سرور باشد.
اگر فایل را باز کنید و تگ globalmodule را پیدا کنید متوجه می‌شوید که تمامی ماژول‌ها در این قسمت معرفی شده‌اند و برای خود یک مدخل ورودی یا همان تگ add را دارند که در آن مسیر فایل dll هم ذکر شده است:
<globalModules> 
 
 <addname="DefaultDocumentModule"image="%windir%\system32\inetsrv\defdoc.dll"/> 
 
 <addname="DirectoryListingModule"image="%windir%\system32\inetsrv\dirlist.dll"/> 

<add name="StaticFileModule"image="%windir%\system32\inetsrv\static.dll"/>
...

 </globalModules>

برای حذف یا جایگزینی یک ماژول به راحتی می‌توانید مدخل ورودی یک ماژول را به صورت دستی حذف نمایید و برای جایگزینی هم بعد از حذف، ماژول خود را معرفی کنید. ولی توجه داشته باشید که این حذف به معنی حذف این ماژول از تمامی اپلیکیشن‌های موجود بر روی IIS هست و سپس اضافه کردن یک ماژول به این بخش. همچنین اگر قصد شما فقط حذف یک ماژول از روی یکی از اپلیکشن‌ها باشد باید از طریق فایل کانفیگ سایت از مسیر تگ‌های <system.webserver><modules> و با استفاده از تگ‌های add و remove به معرفی یک ماژول مختص این اپلیکیشن و یا حذف یک ماژول خاص اقدام نمایید.

PreConditions
این ویژگی می‌تواند در خط معرفی ماژول، مورد استفاده قرار بگیرد. اگر به فایل نگاه کنید می‌بینید که در بعضی خطوط این ویژگی ذکر شده است. تعریف این ویژگی به هسته IIS می‌گوید که این ماژول در چه مواردی و به چه شیوه ای باید به کار گرفته شود.
 <add name="ManagedEngine64" image="%windir%\Microsoft.NET\Framework64\v2.0.50727\webengine.dll" preCondition="integratedMode,runtimeVersionv2.0,bitness64" /> 
 
 <add name="ManagedEngine" image="%windir%\Microsoft.NET\Framework\v2.0.50727\webengine.dll" preCondition="integratedMode,runtimeVersionv2.0,bitness32" /> 
 
<add name="ManagedEngineV4.0_32bit" image="%windir%\Microsoft.NET\Framework\v4.0.30319\webengine4.dll" preCondition="integratedMode,runtimeVersionv4.0,bitness32" /> 
 
<add name="ManagedEngineV4.0_64bit" image="%windir%\Microsoft.NET\Framework64\v4.0.30319\webengine4.dll" preCondition="integratedMode,runtimeVersionv4.0,bitness64" />

مقادیری که precondition میتواند بگیر شامل موارد زیر هستند:
bitness
این گزینه به دو صورت bitness32 و bitness64 یافت می‌شود. امروزه پردازنده‌های 64 بیتی بسیار متداول شده اند و بسیاری از تولید کنندگان دارند به سمت عرضه ابزارهای 64 بیتی رو می‌آورند و به زودی عرضه‌های 32 بیتی را متوقف می‌کنند و به سمت سیستم عامل‌های 64 بیت سوییچ خواند کرد ولی باز هم هنوز برنامه‌های 32 بیتی زیادی هستند که مورد استفاده قرار می‌گیرند و نمی‌توان آن‌ها را نادیده گرفت. برای همین ویندوزهای 64 بیتی مایکروسافت در کنار محیط 64 بیتی‌شان از یک محیط 32 بیت به اسم WOW64 استفاده می‌کنند. در این حالت این امتیاز به شما داده می‌شود که از پروسه‌های کارگر 32 بیتی در کنار پروسه‌های کارگر 64 بیتی استفاده کنید و PreCondition به bitness32 یا bitness64 تنظیم می‌شود تا از صحت بارگزاری dll در یک محیط درست مطمئن شود. در صورتی که این خصوصیت ذکر نشود یک هندلر 32 بیتی و 64 بیتی و یک module map اجرا می‌شود.

Runtime version
اگر ماژول خاصی برای اجرا به ورژن خاصی از net framwork. نیاز دارد، این ویژگی ذکر می‌شود. در صورتی که ماژولی قصد اجرای بر روی فریم ورک اشتباهی داشته باشد سبب خطا خواهد شد.

Mana gedHandler 
با معرفی IIS7 ما با یک مدل توسعه پذیر روبرو شدیم و می‌توانستیم ماژول‌ها و هندلرهای خود را بنویسیم و مستقیما در Pipeline قرار دهیم ولی سوییچ کردن بین دو بخش کدهای مدیریت شده و native یک عمل سنگین برای سیستم به شمار می‌آید و به منظور کاهش این بار گزینه managedhandler قرار داده شده است تا تعیین کند مواقعی که درخواست نیازی به این ماژول ندارد، این ماژول اجرا نگردد. به عنوان مثال فایل‌های ایستا چون jpg یا html و... شامل این ماژول نخواهند شد. واضح‌ترین مثال در این زمینه Forms Authentication می‌باشد و موقعی اجرا می‌شوند که درخواست فایل‌های aspx شده باشد و اگر یک فایل html را درخواست کنید این ماژول امنیتی روی آن اثری ندارد و عملیات شناسایی هویت روی آن اجرا نمی‌شود و اگر می‌خواهید روی همه فایل‌ها، این عملیات شناسایی انجام شود باید خصوصیت "precondition="managedhandler حذف شود.
در صورتی که تگ module را به صورت زیر بنویسید تمامی ماژول‌ها برای تمامی درخواست‌ها اجرا خواهد شد، صرف نظر از اینکه آیا ماژولی به صورت "precondition="managedmodule مقداردهی شده است یا خیر.
<modules runAllManagedModulesForAllRequests="true"/>
 
The Mode Precondition 
تا به الان گفتیم که چگونه میتوانیم یک ماژول و یا هندلر مدیریت شده‌ای را به Pipeline اضافه کنیم؛ ولی IIS7 به بالا نیاز دارد که تا پروسه‌های کارگر را به روشی خاص به این منظور اجرا کند و فریم ورک دات نت را برای اجرای آن‌ها بارگزاری کند. همچنین به اجرای ماژولی به اسم webengine.dll برای مدیریت  ماژولهای مدیریت شده نیازمند است و خود IIS در مورد کدهای مدیریت شده چیزی متوجه نمی‌شود. پس ما برای اینکه IIS را متوجه این موضوع نمائیم، باید Integrated mode را به آن معرفی کنیم.
در نسخه‌های قبلی IIS یک روش قدیمی برای کدهای مدیریت شده وجود داشت که از طریق اینترفیسی به نام ISAPI صورت می‌گرفت. در این حالت ASPNET_ISAPI.DLL مسئول این کار بود و اگر هنوز هم میخواهید از این dll در نسخه‌های جدیدتر IIS کمک بگیرید باید به جای معرفی classic mode ، integration mode را معرفی کنید.
با برابر کردن precondtion به مقدار "intgretedmode" هندلر یا ماژول شما در یک پول با خصوصیت integrated بارگزاری خواهد شد و اگر مقدار آن "classicmode" باشد در یک پول بدون خاصیت integrated بارگزاری می‌شود.
تفاوت بین دو روش کلاسیک و مجتمع integrated بر سر این هست که در روش جدید، ماژول شما به عنوان یک پلاگین برای IIS دیده نمی‌شود و کد شما را جزئی از کامپوننت‌های خود به شمار می‌آورد. به صورت واضح‌تر در حالت کلاسیک موقعی که درخواستی وارد pipeline میشد ابتدا از کامپوننت‌ها و ماژول‌های داخلی خود IIS عبور داده میشد و بعد فایل ASPNET_ISAPI.DLL جهت پردازش کدهای مدیریت شده صدا زده میشد و با توجه به کدهای شما، بعضی مراحل تکرار میشد؛ مثلا اگر کد شما در مورد Authentication بود و بعد از گذر از مراحل auth داخل خود IIS و بقیه موارد دوباره نوبت کد شما و گذر از مراحل authentication بود. یعنی وجود دو pipeline؛ ولی در حالت مجتمع این دوبار انجام وظیفه از بین رفته است چرا که کدهای شما به طور مستقیم در pipeline قرار دارند و آن‌ها را جزئی از خود می‌داند، نه یک پلاگین که افزون بر فعالیت خودشان، اجرای کدهای شما رو هم بر دوش بکشند.
شکل زیر نمونه ای از حالت کلاسیک را نشان می‌دهد که در آن دو بار عمل auth دارد انجام میگیرد.
 



شکل زیر هم نمونه ای حالت مجتمع هست:

 
در کل امروزه دیگر استفاده از روش کلاسیک راهکار درستی نیست و این ویژگی تنها به عنوان یک سازگاری با نمونه کارهای قدیمی است.
تگ‌هایی که از خصوصت precondition استفاده می‌کنند به شرح زیر هستند:
  • ISAPI filters 
  • globalModules 
  • handlers 
  • modules 

در مورد بقیه تگ‌ها در آینده بیشتر بحث می‌کنیم. بهتر هست مطلب را با توضیح precondition جهت ممانعت از طولانی و طومار شدن در اینجا ببندیم و در قسمت آینده دیگر روش‌های نصب ماژولمان را دنبال کنیم.