با وجود همه تمهیداتی که برنامه نویسا تو زمان توسعه یه محصول درنظر میگیرن، اما در زمان اجرا تو کامپیوتر مقصد مسائل و مشکلاتی ممکنه پیش بیاد. بنابراین دادن دسترسی مدیریت بخشی از اپلیکیشن به کاربر در محیط واقعی کاری مفید و مناسب به نظر میرسه. البته دادن این اختیارات باید با احتیاط کامل انجام بشه تا تو روند اجرای برنامه اختلال یا کارشکنی رخ نده.
یکی از روشهایی که برای دادن این اختیارات به کاربر تو دات نت فراهم شده، استفاده از فایلهای کانفیگه. البته وجود این فایلهای کانفیگ کاملا اختیاریه و برای اجرای یه برنامه نیازی به وجود اونا نیست. اما صرفا وجود این فایل کنار فایل اجرایی برنامه باعث میشه تا CLR در ابتدای اجرای برنامه محتوای اون رو بررسی کنه و در صورت نیاز با توجه به تنظیمات موجود، تغییراتی تو روند پیش فرض اجرای برنامه اعمال کنه. البته از این فایلها برای کارهای دیگه ای مثل ذخیره بعضی از تنظیمات هم استفاده میشه که به علت گسترده بودن این موارد تحقیقات بیشتر به خوانندگان واگذار میشه (!).
استفاده از این فایلها برای ذخیره تنظیمات یه برنامه نسبت به استفاده از سایر روشها مثل رجیستری ویندوز، مزایای زیادی رو برای برنامه های دات نتی فراهم کرده. مثلا عملیات نصب و پاک کردن برنامه، پشتیبان گیری از برنامه، انتقال فایلهای برنامه و ... رو خیلی راحتتر کرده. درضمن ساختار این فایلهای کانفیگ بصورت XML بوده و بنابراین براحتی میشه با استفاده از یه ادیتور متنی اونا رو ویرایش کرد. پس با انتقال برخی از تنظیمات برنامه به این فایلها، اجازه کنترل بخشی از برنامه رو میشه براحتی به کاربران داد.
نام و مسیر این فایلهای کانفیگ برای برنامه های دسکتاپ و وب فرق میکنه:
- فایل کانفیگ برنامه های وبی همیشه با نام web.config تولید و استفاده میشه. این فایل باید تو مسیر ریشه سایت قرار داشته باشه. دقت بشه که اسمبلی های یه برنامه وبی معمولا تو پوشه bin که تو ریشه سایت قرار داره قرار داده میشه. البته با توجه به ماهیت خاص پوشه های یه برنامه وبی، هر پوشه موجود تو برنامه هم میتونه برای اعمال تنظیمات مخصوص همون مسیر، یه فایل کانفیگ (با همون نام web.config) داشته باشه.
- برای برنامه های دسکتاپ نام این فایل بصورت نام کامل فایل اجرایی برنامه (به همراه exe.) با پسوند config. تولید میشه. مثلا برای برنامه ای با فایل اجرایی program.exe، فایل کانفیگش باید program.exe.config باشه.
یکی از مواردی که میشه با اعمال تنظیمات خاصی تو فایل کانفیگ یه برنامه انجام داد، تغییر روند کاوش اسمبلی توسط CLR و معرفی اسمبلی های موردنظر به جای اسمبلی های موجود و یا تغییر مسیر جستجوی اونا و یا تعریف مسیرهای جدید برای پیدا کردن و بارگذاری اسمبلی هاست. به این فرایند کاوش و یافتن اسمبلی ها که توسط CLR بصورت خودکار انجام میشه، اصطلاحا assembly probing میگن.
برای روشنتر شدن مطلب یه مثال ساده زده میشه. فرض کنید که تولیدکننده یه نرم افزار با توجه به شرایط موجود تصمیم میگیره تا ساختار مسیر برنامه رو بصورت زیر تنظیم کنه:
تو این برنامه، اسمبلی اجرایی (program.exe) ریفرنسی به اسمبلی lib.dll داره. اما با استفاده از ساختار بالا، چون فایل lib.dll تو مسیر ریشه برنامه و کنار فایل اجرایی نیست، عملا CLR نمیتونه پیداش کنه، و اجرای این برنامه خطای System.IO.FileNotFoundException رو صادر میکنه. برای حل این مشکل همونطور که اشاره شد، میشه از یه سری تنظیمات مخصوص تو فایل کانفیگ برنامه (program.exe.config) استفاده کرد.
تو این تنظیمات خاص، به CLR اعلام میشه که کجاها رو برای یافتن اسمبلی های موردنیاز بگرده. برای اینکار از تگ assemblyBinding که زیر تگ runtime تو تگ ریشه configuration قرار داره، بصورت زیر استفاده میشه:
<configuration> <runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <probing privatePath="utils" /> </assemblyBinding> </runtime> </configuration>
CLR برای پیداکردن فایل یه اسمبلی همیشه مسیر ریشه برنامه (جایی که فایل اجرایی برنامه قرار داره) رو میگرده، و اگه نتونه فایلهای موردنظر رو پیدا کنه به دنبال اونا تو یه سری مسیرهای خاص دیگه میگرده. یکی از این مسیرها مسیریه که تو تنظیمات معرفی شده در بالا تو فایل کانفیگ قرار داره. مثلا برای این مثال تو فولدر utils هم برای یافتن فایل lib.dll میگرده و با پیدا کردنش کار اجرای برنامه رو بدون صدور خطا ادامه میده. تو خاصیت privatePath تگ probing میشه مسیرهای بیشتری رو هم معرفی کرد، فقط باید این مسیرها رو با سمیکالن (;) از هم جدا کرد. این مسیرها میتونن کاملا مطلق و یا نسبت به مسیر ریشه اپلیکیشن تعریف بشن. درباره نحوه رفتار CLR تو فرایند کاوش اسمبلی در ادامه بیشتر بحث میشه.
همونطور که در بالا اشاره شد، CLR برای یافتن فایلها و اسمبلیهای موردنیاز، مسیرهای مختلفی رو میگرده. مثلا، اگه CLR دنبال یه اسمبلی به نام MyAssembly میگرده، و تو تنظیمات probing فایل کانفیگ هم نشانی MyLibFolder آورده شده باشه، مسیرهای زیر رو به ترتیب کاوش میکنه:
AppDir\MyAssembly\MyAssembly.dll
AppDir\MyLibFolder\MyAssembly.dll
AppDir\MyLibFolder\MyAssembly\MyAssembly.dll
بنابراین تو مثال قبلی اگه فایل lib.dll به جای پوشه utils تو پوشه ای به نام lib قرار داشت، نیازی به استفاده از تنظیمات probing تو فایل کانفیگ نبود، چون CLR بصورت پیشفرض به دنبال فایلهای موردنیاز، تو زیرپوشه هایی همنام خود فایل (بدون پسوند) هم میگرده.
اگه با این شرایط، CLR باز هم نتونه فایل موردنظر رو پیدا کنه، جستجو رو با تغییر پسوند dll. به exe. دوباره از اول انجام میده. یعنی مثلا برای مثال این قسمت تو مسیرهای زیر دنبال اسمبلی میگرده:
AppDir\MyAssembly\MyAssembly.exe
AppDir\MyLibFolder\MyAssembly.exe
AppDir\MyLibFolder\MyAssembly\MyAssembly.exe
اگه پس از این تلاش هم اسمبلی موردنیاز پیدا نشه، خطای FileNotFoundException صادر میشه.
برای اسمبلیهای ماهواره ای (satellite assembly) وضعیت کاوش یه کمی پیچیده تره. درمورد این اسمبلیها فرض بر اینه که فایلهای این اسمبلیها، تو زیرپوشه هایی همنام با فرهنگ مربوطه قرار داره. مثلا، تو همین مثال جاری اگه اسمبلی ماهواره ای MySatelliteAsm با فرهنگ fa-IR نیاز باشه، تو مسیرهای زیر برای یافتنش کاوش میشه:
AppDir\fa-IR\MySatelliteAsm\MySatelliteAsm.dll
AppDir\MyLibFolder\fa-IR\MySatelliteAsm.dll
AppDir\MyLibFolder\fa-IR\MySatelliteAsm\MySatelliteAsm.dll
AppDir\fa-IR\MySatelliteAsm.exe
AppDir\fa-IR\MySatelliteAsm\MySatelliteAsm.exe
AppDir\MyLibFolder\fa-IR\MySatelliteAsm.exe
AppDir\MyLibFolder\fa-IR\MySatelliteAsm\MySatelliteAsm.exe
AppDir\fa\MySatelliteAsm.dll
AppDir\fa\MySatelliteAsm\MySatelliteAsm.dll
AppDir\MyLibFolder\fa\MySatelliteAsm.dll
AppDir\MyLibFolder\fa\MySatelliteAsm\MySatelliteAsm.dll
AppDir\fa\MySatelliteAsm.exe
AppDir\fa\MySatelliteAsm\MySatelliteAsm.exe
AppDir\MyLibFolder\fa\MySatelliteAsm.exe
AppDir\MyLibFolder\fa\MySatelliteAsm\MySatelliteAsm.exe
تو این حالت هم CLR به دنبال فایل اسمبلی با پسوند dll. و exe. میگرده. با توجه به توضیحات این قسمت معلوم میشه که فرایند کاوش اسمبلی، یه فرایند نسبتا پیچیده و زمانبره، مخصوصا اگه مسیرهایی تو شبکه های کامپیوتری کاوش بشه. بنابراین تو تعیین ساختار برنامه و اعمال تنظیمات probing باید با دقت و احتیاط کامل عمل کرد.
.: . :.