Этот файл можно редактировать непосредственно, используя программу Блокнот, но следует иметь в виду, что при некорректном изменении этого файла вы можете нарушить работу среды выполнения. Ошибки в этом сценарии могут иметь гораздо более серьезные последствия, чем ошибки в файле *.config приложения, поскольку ошибки XML в файле конфигурации приложения влияют только на данное приложение, в то время как неправильный XML-код в файле machine.config может вообще блокировать работу конкретной версии .NET.
Общая схема связей компоновочных блоков
Теперь, когда мы с вами изучили подробности того, как среда CLR осуществляет поиск запрошенных компоновочных блоков, вспомните о том, что простое на самом деле должно быть простым. Многие (если не все) ваши .NET-приложения будут иметь вид группы приватных компоновочных блоков, размещенных в одном каталоге. В таком случае достаточно просто скопировать соответствующую папку туда, куда требуется, и начать выполнение клиента.
Рис. 11.29. Метод разрешения ссылок компоновочного блока в среде CLR
Однако, вы уже видели, что в процессе разрешения связей среда CLR выполняет проверку на наличие файлов конфигурации клиента и политики публикации компоновочных блоков. В качестве общей схемы пути, который проходит среда CLR при разрешении внешних ссылок компоновочного блока, предлагается схема, показанная на рис. 11.29.
Эта глава посвящена тому, как среда CLR разрешает ссылки на внешние компоновочные блоки. Глава начинается с рассмотрения содержимого компоновочного блока: заголовка, метаданных, манифеста и CIL-кода. Затем рассматриваются создание одномодульных и многомодульных компоновочных блоков, а также нескольких приложении клиента (на разных языках).
Вы смогли убедиться в том, что компоновочные блоки бывают приватными и общедоступными. Приватные компоновочные блоки копируются в подкаталог клиента. Общедоступные компоновочные блоки устанавливаются в глобальный кэш компоновочных блоков (GAC), и при этом они должны быть строго именованными. Наконец, вы узнали о том, что приватные и общедоступные компоновочные блоки можно конфигурировать, используя XML-файлы конфигурации клиента или, как альтернативу, файл политики публикации.
ГЛАВА 12. Отображение типов, динамическое связывание и программирование с помощью атрибутов
Как показано в предыдущей главе, компоновочные блоки являются базовыми элементами установки и среде .NET. С помощью интегрированного обозревателя объектов в Visual Studio 2005 можно рассмотреть открытые типы тех компоновочных блоков, на которые ссылается проект. Внешние средства, такие как ildasm.exe, позволяют увидеть соответствующий CIL-код, метаданные типов и содержимое манифеста компоновочного блока любого бинарного файла .NET, Вдобавок к этим возможностям, доступным во время проектирования компоновочного блока .NET, вы можете получить ту же информацию программными средствами, используя объекты пространства имен System.Reflection. В связи с этим мы выясним роль отображения типов и необходимость использования метаданных .NET.
В оставшейся части главы рассматривается ряд тесно связанных вопросов, относящихся к возможностям сервисов отображений. Например, вы узнаете о том, как .NET-клиент может использовать динамическую загрузку и динамическое связывание для активизации типов., о которых у клиента нет полной информации на этапе компиляции. Вы также узнаете, как с помощью системных и пользовательских атрибутов можно добавить в компоновочный блок .NET пользовательские метаданные. Чтобы продемонстрировать перспективы применения этих (да первый взгляд излишне специальных) возможностей, глава завершится примером построения нескольких "встраиваемых" объектов, которые Вы сможете добавить в расширяемое приложение Windows.Form.
Возможность полного описания типов (классов, интерфейсов, структур, перечней и делегатов) с помощью метаданных является главной особенностью платформы .NET. Многие .NET-технологии, такие как сериализация объектов, удаленное взаимодействие .NET и Web-сервисы XML, требуют, чтобы среда выполнения имела возможность выяснить форматы используемых типов. Возможности межъязыкового взаимодействия, поддержка компилятора и возможности IntelliSense среды разработки тоже зависят от конкретного описания типов.
Читать дальше