یکی از مهمترین ویژگیهای CLR «امنیت نوع» یا Type Safety هست. تو زمان اجرا CLR میدونه که نوع هر شی دقیقا چیه. با استفاده از متد GetType (که تو مطلب قبلی توضیح داده شده) میشه از نوع دقیق شی موردنظر باخبر شد، و ازاونجاکه این متد non-virtual تعریف شده، بنابراین انواع دیگه نمیتونن با override کردن اون، درباره نوعشون اطلاعات غلطی فراهم کنند. مثلا نوع Copper نمیتونه با override و تغییر پیاده سازی این متد نوع Gold رو برگردونه.
تو CLR نیازه تا تمامی انواع در نهایت از کلاس مخصوصی به نام System.Object مشتق بشن. اینکار به دلایل مختلفی انجام میشه و بهترین دلیلی که میشه برای اون آورد همونیه که اریک لیپرت (Eric Lippert) یکی از اعضای سابق تیم طراحی زبان برنامه نویسی #C اینجا آورده: "... در مقایسه با روشهای دیگه، اینکار بیشترین ارزش رو برای برنامه نویسا فراهم میکنه ...". (اطلاعات خیلی بیشتر درباره نحوه کارکرد CLR در رابطه با اشیا)
هنگامیکه که یه اسمبلی برای اجرا به حافظه بارگذاری میشه، CLR کدهای موجود رو بر مبنای متد به متد اجرا میکنه. یعنی برای اجرای یه قطعه کد اونها رو عملا به صورت قطعاتی که کوچکترین واحدش متدها هستند درنظر میگیره و سپس برای اجرای متدها، کد IL موجود رو برای کامپایل JIT به حافظه بارگذاری میکنه و بعدش کار اجرای کدهای کامپایل شده به زبان ماشین رو بصورت خط به خط انجام میده.
اما این وسط تو اجرای این کدها ممکنه ارجاعی به اعضای نوع های دیگه وجود داشته باشه. خب حالا میشه پرسید که CLR دقیقا چیجوری این نوع ها رو شناسایی میکنه؟ چیجوری محل دقیق اونا رو تو اسمبلی هابی که اونا رو تعریف کرده پیدا میکنه؟ و چیجوری کدهای موردنیاز رو به حافظه بارگذاری میکنه؟
با وجود همه تمهیداتی که برنامه نویسا تو زمان توسعه یه محصول درنظر میگیرن، اما در زمان اجرا تو کامپیوتر مقصد مسائل و مشکلاتی ممکنه پیش بیاد. بنابراین دادن دسترسی مدیریت بخشی از اپلیکیشن به کاربر در محیط واقعی کاری مفید و مناسب به نظر میرسه. البته دادن این اختیارات باید با احتیاط کامل انجام بشه تا تو روند اجرای برنامه اختلال یا کارشکنی رخ نده.
تو قسمت قبلی مطالب مقدماتی داده های نسخه اسمبلی ارائه شد. در ادامه و تو این قسمت مباحث تکمیلی این موضوع، شامل شماره نسخه و فرهنگ اسمبلی و همچنین نحوه کار با این داده ها تو ویژوال استودیو (که بیشتر به محیط عملی توسعه نزدیکه) ارائه میشه.
هنگامیکه یه فایل PE برای یه اسمبلی تولید میشه (چه توسط csc.exe و چه بوسیله al.exe)، اطلاعات استانداردی برای نگهداری نسخه کامل اسمبلی هم به اون فایل اضافه میشه. این استاندارد مطابق استاندارد نسخه Win32 هستش. برای آشنایی بیشتر با ساختار داده ای این منبع تو یه فایل استاندارد ویندوزی میشه از اینجا کمک گرفت.
تو قسمت قبلی ابزار AL.exe معرفی شد و روش تولید یه اسمبلی چند فایله با استفاده از این ابزار نشون داده شد. Assembly Linker هم مثل کامپایلر سی شارپ امکان تولید فایلهای اجرایی مختلف رو داره. اینکار هم با استفاده از سوییچهای مختلف زیر انجام میشه:
- CUI (یا Console User Interface) یا همون برنامه کنسول: t[arget]:exe/
- GUI (یا Graphical User Interface) یا همون برنامه با رابط کاربری گرافیکی: t[arget]:winexe/
- Windows Store App یا همون برنامه های فروشگاه ویندوز: t[arget]:appcontainerexe/
تو مطلب «اسمبلی های چند فایله»، روش تولید یه اسمبلی چند فایله با استفاده از کامپایلر سی شارپ نشون داده شد. علاوه بر این روش، راه دیگه ای هم برای تولید چنین اسمبلی هایی وجود داره و اون استفاده از ابزار AL.exe یا Assembly Linker هست. این ابزار رو هم مثل ابزار ILDasm.exe میشه تو SDKهای ویندوز پیدا کرد که به همراه ویژوال استودیو نصب میشه.
تو مطلب ساخت اسمبلی مدیریت شده، درباره نحوه کارکردن با کامپایلر #C بحث شد. روشها و انواع مختلف قابل تولید توسط این کامپایلر شرح داده شد. علاوه بر موارد اشاره شده، این کامپایلر یه سوییچ مهم دیگه برای تولید یه ماژول مدیریت شده هم داره. این سوییچ بصورت t:module/ استفاده میشه و مشخص میکنه که کامپایلر به جای تولید یه اسمبلی کامل فقط باید یه ماژول مدیریت شده تولید کنه.
فایل program.exe محصول مثال مطلب ساخت اسمبلی مدیریت شده، چیزی بیشتر از یه فایل PE به همراه یکسری داده های اضافه مثل جداول متادیتاست. این فایل تو تعریفی پیشرفته تر، یه «اسمبلی» هست. این جداسازی تعریف و متمایز کردنش یعنی چی؟ خب پس اول به تعریف دقیقتر از یه اسمبلی آورده میشه.