ЯЗЫК ПРОГРАММИРОВАНИЯ С# 2005 И ПЛАТФОРМА .NET 2.0. 3-е издание
Шрифт:
Тип класса AppSettingsReader не задает способа записи специальных данных приложения в файл *.config. На первый взгляд это может показаться ограничением, но на самом деле это вполне логично. Сама идея создания файла *.config заключается в том, чтобы он содержал доступные только для чтения данные, которые должны помочь среде CLR (а также типу AppSettingsReader) правильно установить приложение на соответствующей машине.
Замечание. В
Исходный код. Проект AppConfigReaderApp размещен в подкаталоге, соответствующем главе 11.
Файл конфигурации машины
Файлы конфигурации, которые мы с вами рассмотрели в этой главе, имеют одно общее свойство: они относятся к конкретному приложению (вот почему они имеют то же имя, что и соответствующее приложение). Но каждая поддерживающая .NET машина имеет еще и файл, имеющий имя machine.config, который содержит множество параметров конфигурации для управления работой всей платформы .NET (многие из этих параметров не имеют ничего общего с разрешением ссылок на внешние компоновочные блоки).
Платформа .NET использует файл *.config для каждой своей версии, установленной на локальной машине. Файл machine.config для .NET2.0 можно найти в каталоге C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG (номер вашей версии может быть другим). Открыв указанный файл, вы увидите множество XML-элементов, задающих установки ASP.NET, различные параметры безопасности, поддержку отладки и т.д. Но если вы захотите добавить в файл machine.config (с помощью элемента ‹appSettings›) установки для приложений, применимые в рамках всей машины, вы можете сделать и это.
Этот файл можно редактировать непосредственно, используя программу Блокнот, но следует иметь в виду, что при некорректном изменении этого файла вы можете нарушить работу среды выполнения. Ошибки в этом сценарии могут иметь гораздо более серьезные последствия, чем ошибки в файле *.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 среды разработки тоже зависят от конкретного описания типов.
Важность метаданных очевидна и, возможно, именно поэтому они не являются новой идеей, предложенной в рамках .NET Framework. Технологии Java, CORBA и COM уже использовали аналогичные понятия. Например, для описания типов, содержащихся в серверах COM, используются библиотеки COM-типов (по сути, они представляют собой просто скомпилированный IDL-код). Как и COM, библиотеки программного кода .NET также поддерживают метаданные типов. Конечно, метаданные .NET синтаксически совершенно не похожи на IDL (Interface Definition Language – язык описания интерфейсов, используется в COM-технологиях для спецификации интерфейсов объектов COM). Напомним, что просматривать метаданные типов компоновочного блока позволяет утилита ildasm.exe (см. главу 1), Если вы откроете с помощью ildasm.exe любой компоновочный блок *.dll или *.exe, созданный вами в процессе изучения материала этой книги (например, CarLibrary.dll), и нажмете комбинацию клавиш ‹Ctrl+M›, то увидите соответствующие метаданные (рис. 12.1).
- Telegram
- Viber
- Skype
- ВКонтакте