- •Сравнительная характеристика технологий .Net и Java.
- •Промежуточный язык il и байт-код Java. Сравнительная характеристика.
- •Основные принципы построения архитектуры .Net.
- •Сборки (assembly) в среде .Net. Проблема версионности сборок и ее решение.
- •Общая система типов данных в среде .Net. Размерные и ссылочные типы данных.
- •Модель автоматической утилизации динамической памяти, основанная на сборке мусора. Проблема недетерминизма.
- •Модель автоматической утилизации динамической памяти, основанная на аппаратной поддержке (тегированной памяти).
- •Сборка мусора в среде .Net. Построение графа достижимых объектов.
- •Сборка мусора в среде .Net. Механизм поколений объектов.
- •Завершение объектов в среде .Net. Метод Finalize. Список завершаемых объектов (finalization queue) и очередь завершения (freachable queue).
- •Динамические массивы в среде. Net и языке c#.
- •События в среде .Net; реализация событий посредством делегатов.
- •Исключительные ситуации и реакция на них в среде .Net.
- •Средства многопоточного программирования в среде .Net. Автономные потоки. Пул потоков.
- •Асинхронные операции в среде .Net. Асинхронный вызов делегатов.
- •Синхронизация программных потоков в среде .Net. Блокировки.
- •Синхронизация программных потоков в среде .Net. Атомарные (Interlocked-) операции.
- •Мониторы в среде .Net. Ожидание выполнения условий с помощью методов Wait и Pulse.
- •Асинхронный вызов делегатов.
- •Итераторы в среде .Net. Создание и использование итераторов.
- •Атрибуты в среде .Net и языке c#. Создание своих атрибутов.
- •Сервисно-ориентированная архитектура (соа) и ее принципы.
- •Технология wcf. Создание сервиса и клиента.
- •Взаимодействие управляемого и неуправляемого кода в среде .Net на примере вызова функций Windows api.
-
Сборки (assembly) в среде .Net. Проблема версионности сборок и ее решение.
Процесс установки в .NET часто сводится к простому копированию файлов, после чего программа готова к немедленному запуску. Если удалить скопированные файлы, то работать перестает только эта конкретная программа. В этом процессе не используется реестр и не учитываются зависимости между компонентами. Чтобы эта схема нормально работала, в .NET используется концепция сборки.
С технической точки зрения сборка (assembly) в .NET представляет собой минимальную устанавливаемую единицу программного кода. Сборка оформляется в виде автономного ЕХЕ-файла или в виде библиотеки DLL, на которую можно ссылаться из других приложений. Однако сборка содержит нечто большее, чем обычный IL-код, компилируемый и выполняемый исполнительной средой .NET. Как минимум, сборка состоит из одного или нескольких модулей и классов, откомпилированных в IL-код, и метаданных (данных, описывающих данные [Префикс «мета» для подобных абстракций второго порядка позаимствован из метаматематики — области математики, посвященной описанию самих математических объектов.]), которые описывают сборку и функциональность входящих в нее классов. Метаданные являются частью сборки, поэтому в документации сборки названы самодокументируемыми. Во многих ситуациях сборка состоит из одного файла, но встречаются и многофайловые сборки. Например, в сборку могут входить ресурсные файлы, графические изображения и даже дополнительные EXE/DLL-файлы. В любом случае сборка является минимальным объектом .NET, для которого производится контроль версии или задаются привилегии.
В большинстве случаев создаются однофайловые сборки, состоящие из одного ЕХЕ-или DLL-файла.
Сборки бывают закрытыми (private) и общими (shared). Закрытые сборки всегда находятся в каталоге приложения или в одном из его подкаталогов. Общие сборки хранятся в глобальном кэше сборок (GAC, global assembly cache). Начнем с закрытых сборок, поскольку именно они используются по умолчанию для решений, построенных в VS .NET IDE. С общими сборками дело обстоит сложнее, и мы займемся ими позже.
Обычно у закрытых сборок не бывает проблем с несовместимостью версий, однако они требуют дополнительных затрат дискового пространства, если в системе приходится хранить несколько копий одного файла в разных каталогах [В наше время дисковое пространство обходится так дешево, что эти затраты с избытком компенсируются удобствами, связанными с использованием закрытых сборок.]. При создании ссылок на сборку командой Project > Add Reference по умолчанию в каталоге приложения создается новый экземпляр закрытой сборки. Мы рекомендуем по возможности ограничиваться использованием закрытых сборок.
Для управления сборками используются конфигурационные файлы в формате XML. Конфигурационный файл должен находиться в одном каталоге с файлом, содержащим точку входа в сборку. С его помощью можно управлять привилегиями, назначать каталоги для поиска зависимых DLL, а также указывать другие сведения, необходимые для загрузки сборки.
Теоретически сборка может быть устроена весьма сложно, поэтому в нее включается манифест — совокупность всех сведений о сборке, необходимых исполнительной среде (CLR) для загрузки, компиляции (при необходимости) и выполнения сборки. В манифест входят следующие сведения:
информация, необходимая для поиска модулей, от которых зависит работа сборки;
имена всех файлов, входящих в сборку;
имена и метаданные всех сборок и файлов, используемых сборкой;
данные о версии сборки;
информация о типах, используемая исполнительной средой для экспортирования типов из сборки (по аналогии с информацией, находящейся в библиотеке типов СОМ).
Именно благодаря наличию манифеста появляется возможность создания сборок, состоящих из нескольких файлов. Кроме того, данные манифеста заменяют сложную систему регистрации компонентов в реестре.