ЯЗЫК ПРОГРАММИРОВАНИЯ С# 2005 И ПЛАТФОРМА .NET 2.0. 3-е издание полностью

Рис. 11.21. Неправильно! Visual Studio 2005 не позволяет сослаться на общедоступный компоновочный блок путем перехода в папку assembly

Вместо этого на вкладке Browse нужно перейти в каталог \Bin\Debug оригинального проекта (рис. 11.22).

Рис. 11.22. Правильно! В Visual Studio 2005 для ссылки на общедоступный компоновочный блок нужно перейти в каталог \Bin\Debug соответствующего проекта

Учитывая этот (раздражающий) факт, создайте новое консольное приложение C# с именем SharedCarLibClient и проверьте возможность использования своих типов.

using CarLibrary;

namespace.SharedCarLibClient {

 class Program {

 static void Main(string[] args) {

  SportsCar c = new SportsCar;

  Console.ReadLine;

  }

 }

}

После компиляции приложения-клиента, в программе Проводник Windows перейдите в каталог, содержащий файл SharedCarLibClient.exe, и убедитесь в том, что Visual Studio 2006 не скопировала CarLibrary.dll в каталог приложения-клиента. При ссылке на компоновочный блок, манифест которого содержит значение .publickey, Visual Studio 2005 предполагает, что строго именованный компоновочный блок, вероятнее всего, установлен в структуре GAC и поэтому не "утруждает" себя копированием двоичного файла.

Pиc. 11.23. С помощью свойства Copy Local можно "заставить" систему выполнить копирование строго именованной библиотеки программного кода

В качестве краткого замечания укажем на то, что можно "заставить" Visual Studio 2005 скопировать общедоступный компоновочный блок в каталог клиента. Для этого нужно выбрать компоновочный блок из узла References в окне Solution Explorer, а затем в окне Properties (рис. 11.23) установить для свойства Copy Local (копировать в локальную папку) значение True (истина) вместо значения False (ложь).

Напомним, что при генерировании строгого имени компоновочного блока в манифест компоновочного блока записывается значение открытого ключа. Точно так же, когда клиент ссылается на строго именованный компоновочный блок, в его манифест записывается "конденсированное" хешированное значение открытого ключа, обозначенное лексемой .publickey. Если с помощью ildasm.exe открыть манифест SharedCarLibClient.exe, вы увидите там следующее.

.assembly extern CarLibrary {

 .publickeytoken = (21 9E F3 80 C9 34 8A 38)

 .ver 1:0:0:0

}

Если сравнить код открытого ключа, записанный в манифесте клиента со значением для открытого ключа, показанным структурой GAC, вы обнаружите полное совпадение. Напомним, что открытый ключ является одной из составляющих строгого имени, идентифицирующего компоновочный блок. С учетом этого среда CLR загрузит только версию 1.0.0.0 компоновочного блока CarLibrary, открытый ключ которого имеет хешированное значение 219EF380C9348A38. Если среда CLR не найдет компоновочный блок, имеющий такое описание в рамках GAC (и не найдет приватного компоновочного блока с именем CarLibrary в каталоге клиента), то будет сгенерировано исключение FileNotFound (файл не найден).

Исходный код. Проект SharedCarLibClient размещен в подкаталога, соответствующем главе 11.

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

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

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