Создание пакетов установки

Управление политиками сборок

В консоли MMC предусмотрены средства управления политиками версий сборок. В оснастке .NET Configuration 1.1 выбираем вкладку Confugured Assemblies и переходим по ссылке View List of Configured Assemblies. Открывается список сборок, для которых были определены политики. Выбирая нужную сборку и щелкая на ней правой кнопкой мыши, можно изменять свойства политики или удалить ее (рис. 9.31).

Рис. 9.31. Изменение свойств политики управления версиями сборки

В этом же окне при щелчке правой кнопкой мыши на свободном поле и выборе пункта Add открывается окно конфигурирования сборки Configure an Assembly (рис. 9.27).

Файлы конфигурации приложения

Файлы конфигурации приложения — это XML-файлы, которые хранят индивидуальные настройки приложения, такие как строки подключения к базам данных Connection String, адреса удаленных компьютеров и т.д. При загрузке приложения CLR проверяет наличие файла конфигурации и в случае его нахождения считывает из него данные.

Файлы конфигурации имеют расширение .config и располагаются в той же самой папке, что и файл приложения. Название файлов конфигурации формируется от имени приложения — файл NameApplication.exe.config принадлежит приложению NameApplication.exe.

Файлы конфигурации, поскольку они являются документами XML, содержат иерархическую структуру. Главным элементом иерархии является элемент <configuration>. Из-за того, что файл конфигурации представляет собой "правильный" XML-файл, все его элементы чувствительны к регистру символов. В таблице 9.1 представлены некоторые элементы и их атрибуты, которые могут находиться в файле конфигурации.

Выше мы использовали политику управления версиями сборок для указания применения в приложении более новой версии сборки. Сделаем то же самое, используя файл конфигурации.

Скопируйте приложение AssVersion и назовите его AssVersionOne. Изменим строку, возвращаемую методом, на Version One:

using System;

namespace AssVersion
{
  public class MyClass
  {
    
    public static string GetString()
    {
      return "Version One";
    }
  
}

}

Устанавливаем следующие значения атрибутов файла AssemblyInfo.cs:

[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyKeyFile("C:\\StrongKey.snk")]

Компилируем сборку, закрываем проект, копируем всю его папку и называем ее AssVersionTwo. Снова меняем значение возвращаемой строки и значения атрибутов в AssemblyInfo.cs:

using System;

namespace AssVersion
{
  
  public class MyClass
  {
    public static string GetString()
    {
      return "Version Two";
    }
  
}

[assembly: AssemblyVersion("2.0.0.0")]

Компилируем это приложение и добавляем обе сборки в GAC при помощи консоли MMC, предварительно удалив из списка сборки, использованные нами в прошлом примере. Не забудьте также удалить политику управления версиями сборок! Теперь займемся приложением, которое будет использовать эти сборки. Скопируйте папку проекта UsingMyClassFromGAC и назовите ее UsingAssemblyConfig. Открываем проект, в окне Solution Explorer удаляем ссылку на сборку AssVersion и добавляем новую ссылку на сборку из проекта AssVersionOne. Запускаем проект из командной строки Visual Studio .NET (рис. 9.32).

увеличить изображение
Рис. 9.32. Результат запуска приложения UsingAssemblyConfig

Приложение возвращает текстовую строку из первой сборки — Version One. Добавим теперь файл конфигурации приложения — щелкаем правой кнопкой мыши в окне Solution Explorer и в меню выбираем Add\Add New Item… . В появившемся окне прокручиваем список шаблонов до самого конца и выбираем шаблон Application configuration file, и не изменяя его названия^{3При этом мы добавляем рабочий файл конфигурации — в папке проекта появится файл App.config. Псоле компиляции проекта в папке bin\Debug появится файл конфигурации UsingMyClassFromGAC.exe.config, который будет использоваться в приложении.} — App.config — нажимаем OK. Я привожу его содержимое для сборки, подписанной ключом StrongKey.snk:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="AssVersion" publicKeyToken="b19037b107de741b"  
         culture="neutral" />
        <bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0" />  
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

В этом коде мы указываем имя сборки — Ass Version, открытый ключ для приложения (publicKeyToken) — b19037b107de741b и культуру сборки — neutral. Если до этого момента вы воспроизводили все действия самостоятельно, то открытый ключ будет другим. Для просмотра сведений о сборке и открытого ключа, в частности, в консоли MMC, щелкните правой кнопкой на выбранной сборке, выберите ее свойства и в появившемся окне скопируйте значение publicKeyToken (рис. 9.33).

увеличить изображение
Рис. 9.33. Открытый ключ приложения publicKeyToken в окне свойств сборки

Компилируем приложение и запускаем его в командной строке. Результатом выполнения программы будет текст VersionTwo (рис. 9.34).

увеличить изображение
Рис. 9.34. Результат запуска приложения с конфигурационным файлом

Мы не указывали ссылку на сборку новой версии — среда CLR при запуске приложения считала данные о версиях сборок из файла конфигурации, нашла новую версию в GAC и вывела его содержимое в приложение. Этот прием используется для обновления программ через Интернет: пользователь скачивает пакет обновлений, содержащий одну или несколько новых сборок, которые установочный пакет помещает в GAC. В конфигурационном файле приложения заранее заданы названия новых версий сборок — и тогда среда CLR запускает обновленную версию программы без перезагрузки операционной системы. Если сборка не была помещена в GAC, то в конфигурационном файле следует указать путь к новой версии сборки при помощи тега <codeBase>.

На диске, прилагаемом к книге, вы найдете приложения AssVersionOne, AssVersionTwo и UsingAssemblyConfig (Code\Glava9\AssVersionOne, AssVersionTwo, UsingAssemblyConfig).