در قسمتهای قبل (1 و 2) پس از مقدمه ای خلاصه وار، درباره ماژول و اسمبلی و تولیدشون بحث شد. تو این قسمت بیشتر درباره CLR و نحوه بارگذاری و اجرای اون بحث میشه.
اسمبلی ها در دنیای دات نت به دو نوع کلی تقسیم میشن:
- اسمبلی های اجرایی (با پسوند exe.) که به صورت مستقیم قابل اجرا هستن. این نوع اسمبلی ها یک ورودی خاص تو متادیتا برای معرفی متد اصلی یا Main دارن.
- اسمبلی های کتابخونه ای (با پسوند dll.) که مستقیما قابل اجرا نیستن اما حاوی انواعی هستن که تو سایر اسمبلی ها استفاده میشن.
در هر صورت برای اجرای هر اسمبلی تو پلتفرم دات نت به CLR نیاز هست و یا همونطور که قبلا هم اشاره شد، CLR وظیفه مدیریت اجرای کدهای مدیریت شده تو این اسمبلی ها رو برعهده داره. برای اینکار نیازه تا حتما دات نت فریمورک در کامپیوتر مقصد نصب شده باشه.
برای نصب این فریمورک مایکروسافت یک بسته اجرایی مستقل برای هر نسخه تولید کرده که به صورت رایگان توزیع میشه. آخرین نسخه ریلیز شده این فریمورک تا این لحظه 4.5.2 هست. البته تو نسخه های جدیدتر ویندوز به صورت پیش فرض دات نت فریمورک نصب شده.
دات نت فریمورک
یکی از راههای فهمیدن نصب بودن دات نت فریمورک، وجود فایل mscoree.dll تو فولدر system32 تو پوشه ریشه ویندوز (مثلا C:\Windows) هست. تو تصویر زیر موقعیت این فایل و مشخصاتش نشون داده شده:
صرفا وجود این فایل تو این مسیر نشون دهنده نصب بودن دات نت فریمورکه. اما یکی از ویژگیهای این پلتفرم اینه که میشه همزمان چندین نسخه از اون رو تو یه دستگاه نصب کرد. برای پی بردن به نسخه های مختلف نصب شده تو یه کامپیوتر میشه به مسیرهای زیر یه نگاهی انداخت:
%SystemRoot%\Microsoft.NET\Framework
%SystemRoot%\Microsoft.NET\Framework64
%SystemRoot%\Microsoft.NET\Framework64
تصاویر زیر محتوای این دو فولدر تو یه سیستم نشون داده شده:
یه راه دیگه برای تشخیص نسخه های نصب شده دات نت فریمورک، استفاده از ابزار clrver.exe هست. این ابزار مفید و کوچک به همراه Net Framework SDK. نصب میشه. البته درصورت وجود ویژوال استودیو این SDK هم وجود داره. برای استفاده از این ابزار تو یه خط فرمان باید محل نصبش رو دونست. اما راه حل ساده تر استفاده از خط فرمان توسعه ویزوال استودیو هست. اجرای این ابزار نتیجه ای مثل تصویر زیر داره:
این ابزار یه سری سوییچ هم برای نمایش اطلاعات دیگه داره که مطالعش به خوانندگان واگذار میشه.
پلتفرم کامپایل
نکته ای که باید در اینجا بهش اشاره بشه اینه که اگه یه اسمبلی تنها حاوی کدهای مدیریت شده type-safe باشه، کد IL نهایی قابلیت اجرا تو هر پلتفرمی (اعم از 32 بیتی یا 64 بیتی یا حتی روی پردازنده های ARM در ویندورزهای RT و ...) داره. به عبارت دیگه یه اسمبلی مدیریت شده قابلیت اجرا تو هر سیستمی (تقریبا!) داره تا زمانیکه نسخه مناسبی از دانت نت فریمورک روی دستگاه مقصد نصب شده باشه.
البته در برخی موارد بسیار نادر لازم میشه تا این اسمبلی ها برای نوع خاصی از ویندوز یا سیستم سخت افزاری تولید بشن. مثلا اسمبلی هایی که حاوی کدهای مدیریت نشده (unmanaged) یا غیرامن (unsafe) برای ارتباط مستقیم با سایر ابزارها یا برنامه های مدیریت نشده یا native هستن. برای کمک به این موارد نادر کامپایلر #C یه سوییچ خط فرمان به نام platform/ داره . با استفاده از این سوییچ میشه اسمبلی هایی تولید کرد که فقط تو معماری x86 و ویندوز 32 بیتی یا فقط تو معماری x64 و ویندوز 64 بیتی یا فقط تو معماری ARM و ویندوز 32 بیتی RT اجرا بشه. البته اگه از این سوییچ استفاده نشه مقدار پیش فرض anycpu بکار میره و همونطور که در بالا هم اشاره شد اسمبلی تولید شده تو تمام انواع سیستم ها قابل اجراست.
البته در برخی موارد بسیار نادر لازم میشه تا این اسمبلی ها برای نوع خاصی از ویندوز یا سیستم سخت افزاری تولید بشن. مثلا اسمبلی هایی که حاوی کدهای مدیریت نشده (unmanaged) یا غیرامن (unsafe) برای ارتباط مستقیم با سایر ابزارها یا برنامه های مدیریت نشده یا native هستن. برای کمک به این موارد نادر کامپایلر #C یه سوییچ خط فرمان به نام platform/ داره . با استفاده از این سوییچ میشه اسمبلی هایی تولید کرد که فقط تو معماری x86 و ویندوز 32 بیتی یا فقط تو معماری x64 و ویندوز 64 بیتی یا فقط تو معماری ARM و ویندوز 32 بیتی RT اجرا بشه. البته اگه از این سوییچ استفاده نشه مقدار پیش فرض anycpu بکار میره و همونطور که در بالا هم اشاره شد اسمبلی تولید شده تو تمام انواع سیستم ها قابل اجراست.
تو ویژوال استودیو، با استفاده از تنظیمی در تب Build از مشخصات پروژه میشه این سوییچ رو تنظیم کرد. روش کار تو تصویر زیر نشون داده شده:
نکته ای که باید در تصویر بالا بهش دقت کرد گزینه Prefer 32-bit هست. این گزینه تنها زمانیکه گزینه anycpu انتخاب شده باشه در دسترسه. با انتخاب این گزینه ویژوال استودیو از مقدار مخصوص anycpu32bitpreferred برای سوییچ platform/ استفاده میکنه. این مقدار مشخص میکنه که اسمبلی باید به عنوان یک برنامه 32 بیتی اجرا بشه حتی اگه سیستم عامل 64 بیتی باشه. خب حالا این سوال پیش میاد که این تنظیم چه ویژگی خاصی داره؟ درسته، اگه اسمبلی موردنظر استفاده خاصی از ویژگیهای یه سیستم 64 بیتی نمیکنه (مثلا حافظه بیشتر) بهتره که این گزینه انتخاب بشه، چون ویژوال استودیو در زمان دیباگ از ویژگی edit-and-continue در برنامه های 64 بیتی پشتیبانی نمیکنه. اصلا خود ویژوال استودیو به دلایل مختلف نسخه 64 بیتی نداره! درضمن اسمبلی های 32 بیتی میتونن با المانهای COM و سایر dllهای 32 بیتی ارتباط برقرار کنن (و نسخه های 64 بیتی نمیتونن).
براساس این تنظیمات، کامپایلر #C نوع هدر فایل (PE32 یا +PE32) رو میسازه و همچنین یکسری اطلاعات و فلگهایی در هدرهای اسمبلی تولید شده ذخیره میکنه. با استفاده از دو ابزار Dumpbin.exe و CorFlags.exe میشه انواع مختلف داده های موجود در هدرهای یک اسمبلی رو دریافت کرد. مثلا تو تصویر اجرای ساده این دو ابزار بر روی یک اسمبلی ساده امتحان شدن:
dumpbin یه ابزار صرفا گزارشیه که سوییچهای زیادی برای دریافت اطلاعات موردنیاز از فایل موردنظر داره. اما ابزار corflags علاوه بر نشون دادن اطلاعات مناسب از هدر CLR، امکاناتی برای تغییر این داده ها هم داره که مطالعه بیشتر در این زمینه به خوانندگان واگذار میشه. تصویر بالا نشون میده که اسمبلی مربوطه با سوییچ anycpu32bitpreferred کامپایل شده.
هنگام اجرای یه برنامه، ویندوز ابتدا هدر فایل رو بررسی میکنه تا بفهمه چه نوع فضای آدرسی از حافظه رو باید در اختیار برنامه قرار بده. فایلی با هدر PE32 میتونه هم تو فضای آدرس 32 بیتی و هم تو فضای آدرس 64 بیتی اجرا بشه، اما فایلی با هدر +PE32 تنها تو فضای آدرس 64 بیتی قابل اجراست. همچنین بررسی معماری پردازنده موجود تو هدر فایل توسط ویندوز انجام میشه تا مطابق با پردازنده سیستم باشه. نکته آخر اینکه ویندوزهای 64 بیتی به تکنولوژی خاص به WOW64 دارن (به معنی Windows On Windows 64) که اجازه اجرای برنامه های 32 بیتی رو میده.
جدول زیر اطلاعات مختلفی راجع به مقادیر مختلف سوییچ platform/ کامپایلر #C میده:
| سوییچ platform/ | نوع هدر | ویندوز 32بیتی | ویندوز 64بیتی | ویندوز RT |
|---|---|---|---|---|
| anycpu | PE32/agnostic | 32 بیتی | 64 بیتی | 32 بیتی |
| anycpu32bitpreferred | PE32/agnostic | 32 بیتی | 32 بیتی | 32 بیتی |
| x86 | PE32/x86 | 32 بیتی | wow64 | اجرا نمیشه |
| x64 | PE32+/x64 | اجرا نمیشه | 64 بیتی | اجرا نمیشه |
| ARM | PE32/ARM | اجرا نمیشه | اجرا نمیشه | 32 بیتی |
بارگذاری CLR
پس از اینکه ویندوز با بررسی هدر فایل تصمیم به تولید یه پراسس 32 یا 64 بیت گرفت، نسخه مناسبی از MsCorEE.dll رو به حافظه بارگذاری میکنه.
- نسخه 32 بیتی از این فایل در ویندوز 32 بیتی (در معماریهای x86 و ARM) تو فولدر system32 موجوده.
- نسخه 32 بیتی این فایل در ویندوز 64 بیتی در فولدر SysWow64 در پوشه ریشه ویندوز (در کنار فولدر system32) قرار داره.
- نسخه 64 بیتی این فایل در ویندوز 64 بیتی تو فولدر system32 (برای پشتیبانی از نسخه های قدیمی اسم این فولدر تو ویندوزهای 64 بیتی تغییر نکرده) قرار داره.
.: در ادامه نحوه اجرای یه اسمبلی شرح داده میشه.
پس از بارگذاری نسخه مناسب MsCorEE.dll، ثرد اصلی پراسس برای آغاز به کار CLR متدی خاص تو این فایل رو فراخوانی میکنه. پس از آغاز به کار CLR فایل exe اسمبلی موردنظر به حافظه بارگذاری شده و نقطه ورودی برنامه (متد Main) اجرا میشه.
درصورتیکه یه برنامه native (با کد مدیریت نشده) درخواست بارگذاری یه اسمبلی مدیریت شده رو بکنه، ویندوز میدونه که برای پردازش کدهای اسمبلی مدیریت شده ابتدا باید CLR رو طبق فرایندی که در بالا شرح داده شده بارگذاری کنه (اگه قبلا بارگذاری نشده باشه). البته تو این حالت بدلیل اینکه پراسس اجرایی قبلا ایجاد شده یه سری محدودیت برای اجرای اسمبلی مدیریت شده وجود داره. برای مثال اسمبلی کامپایل شده برای پلتفرم x86 نمیتونه تو یه پراسس 64 بیتی بارگذاری بشه. البته این اسمبلی میتونه با استفاده از تکنولوژی WOW64 ویندوز 64 بیتی تو یه پراسس 32 بیتی اجرا بشه.
نکته: با استفاده از Environment.Is64BitOperatingSystem میشه از 64 بیتی بودن سیستم عامل جاری مطلع شد. همچنین با استفاده از Environment.Is64BitProcess میشه از 64 یا 32 بیتی بودن پراسس جاری اطلاع پیدا کرد.
.: در ادامه نحوه اجرای یه اسمبلی شرح داده میشه.
CLR به زبان ساده - قسمت اول: پیشگفتار
CLR به زبان ساده - قسمت دوم: اسمبلی
CLR به زبان ساده - قسمت سوم: بارگذاری
CLR به زبان ساده - قسمت چهارم: اجرا
CLR به زبان ساده - قسمت پنجم: IL و بررسی کد
CLR به زبان ساده - قسمت ششم: NGen.exe
CLR به زبان ساده - قسمت هفتم: FCL و CTS
CLR به زبان ساده - قسمت هشتم: CLS
CLR به زبان ساده - قسمت نهم: کد مدیریت نشده
