یکی از مهمترین خصوصیات CLR این است که نوعها، ایمن هستند و همواره میداند که هر شیء از چه نوعی است. برای اثبات این ادعا میتوانید متد GetType را صدا بزنید تا به شما بگوید این شیء از چه نوعی است. متد GetType قابلیت رونویسی ندارد و به همین علت میتوانید مطمئن باشید که خروجی برگشتی دستکاری نشده است.
یکی از نیازهای طراحان این است که مرتبا نیاز به تبدیل نوعها را به یکدیگر دارند. CLR به شما اجازه میده ...
آغاز فصل چهارم: بنیان و اساس نوعها (Type Fundamentals) در این فصل قرار است به بررسی اساس نوع دادهها بپردازیم؛ اینکه رفتارهایی که باید از هر نوع Type انتظار داشته باشیم، چه چیزهایی هستند. معانی فضای نام، اسمبلیها، امن بودن نوعها (Safety) و تبدیلات (Casts) را بهتر درک کنیم.
اولین نکتهای که باید بدانید این است که هر نوع دادهای که شما در دات نت دارید و تعریف میکنید، از والدی به نام System.Object مشتق میشود. برای مث ...
در قسمت قبل یاد گرفتیم که اگر یک ناشر، باگی را در یک اسمبلی برطرف کند، باید مدیر سیستم با تغییر فایل پیکربندی، نسخهی جدید اسمبلی را به CLR معرفی کند. ولی اگر ناشر بخواهد این اسمبلی را در اختیار همهی کاربرانش قرار دهد و به همهی کاربران بگوید که باید فایل را تغییر دهید، این روش آن چنان راحت و مناسب نیست. به همین دلیل ناشر باید یک فایل تعیین سیاست داشته باشد، تا این کار راحت صورت بگیرد.
بیایید فرض کنیم که شما، ناشر این ا ...
در ادامه قسمت قبلی ، به خصوصیات و ویژگیهای اسمبلی قوی میپردازیم: اسمبلیهای نام قوی در برابر دستکاری مقاوم هستند
از آنجائیکه محتویات اسمبلی، هش شده و مقدار هش آن امضا میشود، در نتیجه اگر
شخصی به دستکاری اسمبلی اقدام کرده باشد یا اینکه فایل مد نظر آسیب دیده
باشد، به راحتی قابل شناسایی است و آن اسمبلی به عنوان اسمبلی صحیح شناسایی
نخواهد شد و نمیگذارد در GAC ثبت شود. ...
آغاز فصل سوم: در فصل گذشته در مورد بسته بندی و توزیع اسمبلیها، بررسیهایی را انجام
دادیم. در این نوع توزیع، فرض ما بر این بود که دسترسی به اسمبلیها، از طریق
دایرکتوری خود اپلیکیشن میباشد؛ ولی برای اسمبلیهای عمومی، صحبتی به میان نیاوردیم.
در این فصل، ما تمرکز خود را برای توزیع اسمبلیهای عمومی میگذاریم. اسمبلیهای عمومی این قابلیت را میدهند که از طریق چند اپلیکیشن قابل دسترسی باشند. سادهترین و قابل دسترسترین ...
در قسمت قبلی با نحوه انتشار برنامهها آشنا شدیم. در این قسمت نحوه پیکربندی یا تغییر پیکربندی برنامه را مشخص میکنیم.
کاربر یا مدیر سیستم بهتر از هر کسی میتواند جنبههایهای مختلف اجرای
برنامه را مشخص کند. به عنوان نمونه ممکن است مدیر سیستم بخواهد
فایلهای یک برنامه را سمت هارد دیسک سیستم کاربر انتقال دهد یا اطلاعات
مانیفست یک اسمبلی را رونویسی کند و مباحث نسخه بندی که در آینده در مورد
آن صحبت میک ...
در فصل دوم کتاب تا به الان یاد گرفتیم چگونه ماژولها را کامپایل کنیم و چگونه آنها را در یک اسمبلی قرار دهیم. حال وقت آن فرا رسیده است که با بسته بندی کردن (Package) و انتشار آن (Deploy) به طوری که کاربران بتوانند برنامه را اجرا کنند آشنا شویم.
نصب برنامه از طریق فروشگاه ویندوز
در فروشگاه ویندوز Windows Store Apps قوانین سخت و شدیدی برای بسته بندی کردن اسمبلیها وجود دارد. ویژوال استود ...
در قسمت قبلی با نحوهی نسخه بندی اسمبلیها آشنا شدیم؛ ولی به غیر از نسخه
بندی، فرهنگ (culture) هم قسمتی از عوامل شناسایی یک اسمبلی است. به عنوان
نمونه من میتوانم یک اسمبلی داشته باشم که برای زبان آلمانی، انگلیسی
آمریکایی، انگلیسی بریتانیایی و ... آماده شده است. شناسایی فرهنگ یک اسمبلی از طریق یک رشته است که شامل یک تگ اصلی و ثانویه طبق استاندارد RFC1766 میباشد. جدول زیر تعدادی از این تگها را نمایش میدهد. ...
در مقاله قبلی در مورد افزودن منابع به اسمبلی صحبتهایی کردم که قسمتی از این منابع مربوط به اطلاعات نسخه بندی بود. در این مقاله قصد داریم این مسئله را بازتر کرده و در مورد نحوهی نسخه بندی بیشتر صحبت کنیم.
در مقالهی قبلی وقتی نسخهی یک اسمبلی را مشخص میکردیم، از 4 عدد که با نقطه از هم جدا شده بودند، استفاه کردیم که در جدول زیر این 4 نامگذاری را مشاهده میکنید: شماره بازبینی Revision Number ...
در مقاله قبلی بحث Assembly Linker را باز کردیم و یاد گرفتیم که چگونه میتوان با استفاده از آن ماژولهای مختلف را به یک اسمبلی اضافه کرد. در این قسمت از این سلسله مقالات قصد داریم فایلهای منابع (Resource) مانند مواد چندرسانهای، چند زبانه و .. را به آن اضافه کنیم. یک اسمبلی حتی میتواند تنها Resource باشد.
...