Net framework 5, а также среды Visual Studio 2012 и C#

Глава 3.
 совместно используемые 
сборки и сборки со строгим 
именем
В главе 2 говорилось о построении, упаковке и развертывании сборок. При этом 
основное внимание уделялось 
закрытому развертыванию
(private deployment), 
при котором сборки, предназначенные исключительно для одного приложения, 
помещают в базовый каталог приложения или в его подкаталог. Закрытое раз-
вертывание сборок позволяет в значительной мере управлять именами, версиями 
и поведением сборок.
В этой главе мы займемся созданием сборок, которые могут совместно исполь-
зоваться несколькими приложениями. Замечательный пример глобально развер-
тываемых сборок — это сборки, поставляемые вместе с Microsoft .NET Framework, 
поскольку почти все управляемые приложения используют типы, определенные 
Microsoft в библиотеке классов .NET Framework Class Library (FCL).
Как уже было отмечено в главе 2, операционная система Windows получила репу-
тацию нестабильной главным образом из-за того, что для создания и тестирования 
приложений приходится использовать чужой код. В конце концов, любое прило-
жение для Windows, которое вы пишете, вызывает код, созданный разработчиками 
Microsoft. Более того, самые разные компании производят элементы управления, 
которые разработчики затем встраивают в свои приложения. Фактически такой 
подход стимулирует сама платформа .NET Framework, а со временем, вероятно, 
число производителей элементов управления возрастет.
Время не стоит на месте, как и разработчики из Microsoft, как и сторонние про-
изводители элементов управления: они устраняют ошибки, добавляют в свой код 
новые возможности и т. п. В конечном счете, на жесткий диск пользовательского 
компьютера попадает новый код. В результате в давно установленном и прекрасно 
работавшем пользовательском приложении начинает использоваться уже не тот 
код, с которым оно создавалось и тестировалось. Поведение такого приложения 
становится непредсказуемым, что, в свою очередь, негативно влияет на стабиль-
ность Windows.
Решить проблему управления версиями файлов чрезвычайно трудно. На самом 
деле, я готов спорить, что если взять любой файл и изменить в нем значение одного-
единственного бита с 0 на 1 или наоборот, то никто не сможет гарантировать, что 
программы, использовавшие исходную версию этого файла, будут работать с новой 
версией файла, как ни в чем не бывало. Это утверждение верно хотя бы потому, что 
многие программы случайно или преднамеренно эксплуатируют ошибки других 

---

95
Два.вида.сборок.—.два.вида.развертывания
программ. Если в более поздней версии кода какая-либо ошибка будет исправлена, 
то использующее его приложение начинает работать непредсказуемо.
Итак, вопрос в следующем: как, устраняя ошибки и добавляя к программам 
новые функции, гарантировать, что эти изменения не нарушат работу других при-
ложений? Я долго думал над этим и пришел к выводу — это просто невозможно. 
Но, очевидно, такой ответ не устроит никого, поскольку в поставляемых файлах 
всегда будут ошибки, а разработчики всегда будут одержимы желанием добавлять 
новые функции. Должен все же быть способ распространения новых файлов, по-
зволяющий надеяться, что любое приложение после обновления продолжит заме-
чательно работать, а если нет, то 
легко
вернуть приложение в последнее состояние, 
в котором оно прекрасно работало.
В этой главе описана инфраструктура .NET Framework, призванная решить про-
блемы управления версиями. Позвольте сразу предупредить: речь идет о сложных 
материях. Нам придется рассмотреть массу алгоритмов, правил и политик, встроен-
ных в общеязыковую исполняющую среду (CLR). Помимо этого, упомянуты многие 
инструменты и утилиты, которыми приходится пользоваться разработчику. Все это 
достаточно сложно, поскольку, как я уже сказал, проблема управления версиями 
непроста сама по себе и то же можно сказать о подходах к ее решению.