Конфигурационните файлове в .NET Framework са текстови файлове в XML формат и служат за задаване на различни настройки на .NET приложенията. Съществуват няколко вида конфигурационни файлове:
Конфигурационен файл за настройките на машината - Machine.config – този файл се намира в %runtime install path%\Config (например C:\WINDOWS\Microsoft.NET\Framework\ v1.1.4322\Config) и съдържа настройки оказващи влияние върху CLR за локалния компютър.
Конфигурационни файлове на приложенията – съдържат настройки, специфични за дадени приложения. Те са два вида: за уеб-базирани приложения се казват винаги Web.config и се намират в коренната директория на уеб приложението или уеб услугата в Internet Information Server и за Windows-базирани приложения – образуват се от името на приложението с .config разширение (например: ако имаме приложение MyLibrary.dll, конфигурационният му файл ще се казва MyLibrary.dll.config).
Publisher Policy File – указват на всички приложения да използват по-нова версия на външно асембли от тази, спрямо която са били компилирани (version redirect). По-нататък ще разгледаме как се използват (вж. Създаване на Publisher Policy File).
Конфигурационни файлове за сигурността (security policy) – съдържат описание на правата за изпълнение на инсталираните асемблита. В .NET Framework съществуват няколко нива на сигурност:
ниво организация
ниво машина
ниво потребител
Следващата таблица показва тяхното местоположение в зависимост от операционната система:
Всички тези конфигурационни файлове са важни за разпространението на .NET приложенията, на което ще се спрем след малко.
Как CLR намира асемблитата?
Важно e за разработването и разпространението на .NET приложения да се познава как CLR търси асемблитата, които дадено приложение изисква, за да се изпълни. По подразбиране CLR се опитва да намери асемблитата със същата версия, с която приложението е било компилирано. Когато .NET приложение изиска външно асембли, се изпълняват следните стъпки:
Определя се вярната версия на нужното асембли – чрез проверяване на конфигурационните файлове (за настройките на машината, на приложението и publisher policy file).
Проверява се дали приложението е използвало асембли със същото име. В такъв случай се зарежда последното използвано асембли.
Проверява се Global Assembly Cache. Ако асембли със същото име се намира там, се използва то.
Изпълнява се търсене на асембли (assembly probing) чрез следните стъпки:
Ако конфигурационните файлове не променят версията на изискваното асембли, тогава CLR се опитва да налучка местоположението му като се базира на неговото име.
Ако е намерен елемент в конфигурационните файлове се търси само в пътя, посочен там. Ако асемблито не е намерено, се регистрира грешка и се прекратява търсенето.
Търси се в поддиректориите, посочени в секцията на конфигурационния файл на приложението. Ако не е намерено асемблито, се прави заявка към Windows Installer да инсталира изискваното асембли. Тази възможност на Windows Installer се нарича инсталиране при заявка (install-on-demand).
За асемблита, които не са силно именувани, CLR не проверява GAC за тяхното наличие и не проверява версията.
Пример 1: Търсене на асембли (probing)
За да поясним описания процес, ще дадем един пример. Нека имаме Windows-базирано приложение BaseDir\MyApp.exe, което използва ресурси от асембли MyLibrary, което не е силно именувано. Конфигурационният файл MyApp.exe.config съдържа:
MyApp.exe.config
При стартиране на MyApp.exe асемблито MyLibrary се търси в следните директории:
С помощта на инструмента Assembly Binding Log Viewer (Fuslogvw.exe), който е част от .NET Framework SDK, може да се разгледа детайлно в кои директории и в какъв ред търси CLR асемблитата.
Пример 2: Търсене на асембли с тага
Нека разширим малко предходния пример. Добавяме в конфигурационния файл MyApp.exe.config таг в частта между таговете и .
MyApp.exe.config
href="CodeBase\MyLibrary.dll" />
При стартиране на MyApp.exe асемблито MyLibrary се вече търси в само в посочената директория:
При посочен таг CLR търси асембли само с посочено име и само в посочената директория. Ако не бъде намерено асемблито, търсенето се прекратява и се съобщава за грешка.
Създаване на Publisher Policy File
Файловете с политика на издателя (publisher policy file) са специален вид конфигурационни файлове, които се компилират и инсталират в Global Assembly Cache и указват на всички приложения да използват по-нова версия на външно асембли от тази, спрямо която са били компилирани (version redirect).
Използването на такива файлове можем да демонстрираме чрез няколко стъпки:
Създаваме publisher policy file с име pubPolicy.config. Целта на този файл е да укаже на CLR при извикване на асемблито с посочения манифест (име - myRedirectedAssembly, публичен ключ - 32ab4ba45e0a69a1, версия - 1.0.0.0) да се зареди асембли със същото име и публичен ключ, но версия 2.0.0.0.
pubPolicy.config
publicKeyToken="32ab4ba45e0a69a1" />
-- Redirecting to version 2.0.0.0 -->
newVersion="2.0.0.0"/>
Компилираме на publisher policy file до publisher policy assembly. Ще използваме създадения файл, за да създадем асембли и да го именуваме силно (ще използваме същия файл, който създадохме в точката Създаване на силно именувано асембли. Това става с помощта на инструмента Assembly Linker (al.exe):
al /link:pubPolicy.config /out:policy.1.0.myRedirectedAssembly.dll /keyfile:keypair.snk
Изходът от тази команда е асембли, записано във файл с име policy.1.0.myRedirectedAssembly.dll.
Добавяне в GAC. Необходимо е така създаденото Publisher Policy Assembly да бъде добавено в Global Assembly Cache. Това става със следната команда:
gacutil /i policy.1.0.myRedirectedAssembly.dll
(За повече информация вж. http://msdn.microsoft.com/library/default.asp? url=/library/en-us/cpguide/html/cpconcreatingpublisherpolicyfile.asp).