Нашли ошибку или опечатку? Выделите текст и нажмите

Поменять цветовую

гамму сайта?

Поменять
Обновления сайта
и новые разделы

Рекомендовать в Google +1

Конфигурирование разделяемых сборок

81

Как и приватные сборки, разделяемые сборки можно конфигурировать за счет добавления в клиентское приложение файла *.config. Разумеется, поскольку разделяемые сборки развертываются в хорошо известном месте (в поддерживаемом в .NET 4.0 кэше GAC), использовать для них элемент <privatePath>, как для приватных сборок, не требуется (хотя, если в клиенте применяются и разделяемые, и приватные сборки, элемент <privatePath> может присутствовать в файле *.config).

Конфигурационные файлы приложения вместе с разделяемыми сборками могут использоваться, когда необходимо заставить CLR-среду привязаться к другой версии отдельной сборки, обойдя значение, которое записано в манифесте клиента. Это может быть удобно по нескольким причинам. Например, предположим, что была выпущена версия 1.0.0.0 сборки, в которой через какое-то время обнаружился серьезный дефект. Одна из возможных мер предусматривает переделку клиентского приложения так, чтобы оно ссылалось на правильную, не содержащую дефекта сборку (с версией, например, 1.1.0.0), и передачу приложения и новой библиотеки на все целевые машины.

Другой вариант состоит в поставке новой библиотеки кода и файла *.config, который указывает исполняющей среде использовать новую (лишенную дефекта) версию. После установки этой новой версии в GAC не понадобится ни компилировать, ни распространять исходное клиентское приложение заново.

Давайте рассмотрим еще один пример. Предположим, что была поставлена первая лишенная дефектов версия сборки (1.0.0.0), а через пару месяцев в нее были добавлены новые функциональные возможности, в результате чего получилась новая версия 2.0.0.0. Очевидно, что существующие клиентские приложения, которые компилировались с версией 1.0.0.0, не будут иметь никакого понятия о появлении новых типов, поскольку в их кодовой базе те никак не упоминаются. В новых клиентских приложениях, однако, ссылка на новые функциональные возможности, предлагаемые в версии 2.0.0.0, добавиться должна. В этом случае можно поставить на целевые машины сборку версии 2.0.0.0 и сделать так, чтобы она могла работать вместе со сборкой версии 1.0.0.0.

В случае необходимости существующие клиенты могут динамически перенаправляться для загрузки версии 2.0.0.0 (чтобы получить доступ к реализованным в этой версии улучшениям) с использованием конфигурационного файла, при этом компилировать и развертывать клиентское приложение заново не понадобится.

Пример конфигурации сборки

Давайте рассмотрим пример использовавшейся в предыдущих статьях сборки fontinfo.dll и предположем, что нам пришлось модифицировать данную библиотеку классов и добавить ещё один класс:

...
public class FontStyle : FontColor
    {
        public char Style;

        public FontStyle(string Name, int FontSize, string Color, char Style) 
            : base (Name, FontSize, Color)
        {
            this.Style = Style;
        }

        public string MyStyle()
        {
            string str;
            switch (this.Style)
            {
                case 'b':
                    str = "жирный";
                    break;
                case 'i':
                    str = "курсив";
                    break;
                default:
                    str = "неопределено";
                    break;
            }
            return str;
        }

        public override void InfoByFont()
        {
            base.InfoByFont();
            Console.WriteLine("Стиль: "+this.MyStyle());
        }
    }

Прежде чем снова компилировать новую библиотеку, обновим номер версии с 1.0.0.0 на 2.0.0.0. Вспомните, что это можно сделать визуально, дважды щелкнув на значке Properties в окне Solution Explorer, а затем щелкнув на кнопке Assembly Information (Сведения о сборке) внутри вкладки Application (Приложение). В отрывшемся диалоговом окне соответствующим образом измените значения в полях Assembly Version (Версия сборки), как показано на рисунке:

Изменение номера версии сборки

Если теперь заглянуть в каталог \bin\Debug проекта, можно заметить, что в нем появилась новая версия сборки (2.0.0.0). Инсталлируем новую версию сборки в GAC для .NET 4.0 с помощью утилиты gacutil.ехе. Обратите внимание, что после этого на машине будут присутствовать две версии одной и той же сборки.

Пройди тесты