Урок 17. Сборки .NET

Семнадцатый урок учебника объектно-ориентированного программирования C# рассматривает .NET-сборки. Строительными блоками .NET-программ, сборок являются файлы, содержащие весь код, информацию об управлении версиями и ресурсы для приложения.

Что такое сборка?

Сборки являются важным понятием в программировании .NET. Сборка-это файл, который содержит программу или библиотеку кода, элементы управления, ресурсы или другую информацию, которая может быть использованы программой. Вообще говоря, сборка создается как единый проект в Visual Studio или аналогичной среде разработки и компилируется в исполняемый файл (EXE) или динамическую связанную библиотеку (DLL).

Сборки не следует путать с пространствами имен. Хотя во многих случаях одна сборка будет содержать одно пространство имен, возможно, что пространство имен будет распределено по многим скомпилированным библиотекам DLL. Аналогично, одна сборка может содержать любое количество пространств имен.

Сборки хранят четыре типа информации. Это:

• Манифест сборки
• Метаданные
• Код промежуточного языка Microsoft (MSIL)
• Ресурсы

Манифест сборки

Манифест сборки содержит сведения, описывающие сборку. В нем имеется:

• Имя сборки. Простая текстовая строка, содержащая имя сборки. Это сочетается с номером версии сборки, языком и региональными параметрами и строгим именем для создания идентификатора сборки.
• Номер версии. Номер версии состоит из основных и второстепенных номеров версий, а также номеров версий и сборок. Эта информация используется платформой .NET framework для обеспечения загрузки соответствующей версии сборки при выполнении программного обеспечения.
• Локализация. Информация о локализации для сборки. Этот параметр используется для глобальных приложений для определения языка или локали, которые поддерживает сборка. Информация о языке и региональных параметрах используется вспомогательными сборками. Это специальные файлы, содержащие подробные сведения о местоположении, такие как перевод текстовых строк на другие языки. Вспомогательные сборки загружаются во время выполнения, если они доступны для предпочтительного языка и региональных параметров пользователя. Их использование выходит за рамки данной статьи.
• Подпись сборки. Содержит открытый ключ от издателя программного обеспечения при назначении строгого имени. Подписанные сборки защищены цифровой подписью, чтобы платформа .NET framework могла предотвратить выполнение сборок, измененных после компиляции. Это снижает риск того, что вирусы и другие вредоносные программы могут изменить содержимое файлов.
• Список файлов. Простые сборки обычно содержат только один файл. Однако можно создать несколько файловых сборок. В любом случае, список файлов в сборке хэшируется и хранится в этом списке.
• Справочная информация. Содержит информацию, используемую во время выполнения, которая сопоставляет ссылку на тип с файлом, содержащим объявление типа и код.
• Сведения о ссылках. Предоставляет список других сборок, на которые ссылается текущая сборка. Каждая ссылка содержит первые четыре элемента из этого списка, т. е. удостоверение сборки.
• Информационные атрибуты. Дополнительная информация. Эти параметры включают такие данные, как сведения о компании для поставщика программного обеспечения, сведения об авторских правах и сведения о продукте и товарном знаке. Эта информация обычно настраивается в AssemblyInfo.cs - файле.

Метаданные

Метаданные типа, хранящиеся в сборке, содержат сведения обо всех типах данных и элементах, предоставляемых сборкой. Это позволяет сборке описывать скомпилированный код, который она содержит. Это особенно полезно при создании программного обеспечения, использующего несколько языков .NET, поскольку каждый язык может проверять метаданные типа и автоматически понимать используемые типы данных. В этой ситуации не требуется писать код взаимодействия пользовательских языков.

Код промежуточного языка Майкрософт

Третьим элементом сборки является программный код. Разрабатываемые классы C# компилируются в Microsoft Intermediate Language (MSIL). Этот язык имеет более низкий уровень, чем C#, но не полностью скомпилирован в машинные инструкции. Окончательная компиляция выполняется только во время выполнения, что дает возможность выполнять код MSIL в среде CLR .NET на различных платформах, включая 32-разрядные и 64-разрядные Windows, а в некоторых случаях и не-Windows операционные системы.

Второе преимущество MSIL заключается в том, что код в сборке может быть использован любым языком .NET. Это позволяет модулям, разработанным в C#, например, использоваться разработчиками Visual Basic и C++.

Существуют недостатки в двухкомпонентной компиляции сборок .NET. Основная проблема для многих разработчиков-это производительность. Дополнительная компиляция времени выполнения действительно вызывает заметную паузу, когда запускается большая программа и скорость выполнения может быть ниже, чем с машинным кодом. Для разработчиков пакетного программного обеспечения вводится дополнительная проблема безопасности кода, так как незащищенный код может быть "декомпилирован" в исходный код C#. Это несколько облегчается за счет использования кодовых обфускаторов. Однако они выходят за рамки данной статьи. В-третьих, использование MSIL требует, чтобы соответствующая версия .NET framework была установлена на всех целевых системах.

Ресурсы

Заключительная секция сборки располагает своими ресурсами. Ресурсы включают все остальные элементы, необходимые для сборки, которые не включены в код. Примеры включают в себя изображения, значки, звуки и локализованный текст.

DLL-ад

До появления сборок .NET операционная система управляла динамическими связанными библиотеками Win32 (DLL), содержащими код, используемый несколькими приложениями. Каждая библиотека DLL будет зарегистрирована в Windows, но только одна версия будет доступна в любое время. Это привело к появлению фразы "DLL Hell", которая описывала проблемы, которые возникали, когда две программы использовали одну и ту же DLL, но требовали разных версий. Если бы более новая версия DLL была совместима со старой версией, то обе программы работали бы так, как ожидалось. Однако, если новая версия нарушила совместимость, старое приложение не будет работать.

Версия сборки

.NET assemblies решила проблему DLL Hell, удерживая свои собственные сведения о версии и имя и версию для всех других, связанных сборок, а не позволяя этому быть продиктованым операционной системой. Теперь на целевой компьютер можно установить несколько версий библиотеки DLL, и среда CLR будет использовать набор правил для определения версии, которая будет использоваться исполняющей программой.

Места сборки

Чтобы среда CLR могла определить правильную версию связанной сборки для использования, ей разрешено искать в трех местах. Первое проверенное расположение-это глобальный кэш сборок (GAC). Это машинное хранилище для сборок, которые могут совместно использоваться несколькими приложениями.

Если требуемая сборка не найдена в GAC, расположение файлов приложения проверяется с помощью процесса поиска, называемого зондированием . Сначала проверяется базовая папка приложения, а затем любая папка с тем же именем, что и сборка. Например, если обнаруживаемая сборка имеет имя "MyAssembly" и приложение установлено в C:\\MyProgram папка, следующие четыре пути будут прощупаны:

C:\MyProgram\MyAssembly.dll
C:\MyProgram\MyAssembly\MyAssembly.dll
C:\MyProgram\MyAssembly.exe
C:\MyProgram\MyAssembly\MyAssembly.exe

Сборки, расположенные в папке приложения, называются частными сборками. Это связано с тем, что сборка может использоваться только приложениями, установленными в папке, поэтому они не могут быть общедоступными. Однако, поскольку сборка не должна быть установлена в GAC, целые программы могут быть установлены с помощью простого копирования файлов.

Примечание: сборки могут быть расположены в других вложенных папках приложения, но эти папки должны быть добавлены в раздел app.config файл.

Наконец, сборки можно установить с помощью кодовой базы. При этом используется запись в файле конфигурации компьютера для определения местоположения в сети или на FTP-узле, где сборка может быть найдена и загружена для ее первого использования.

Для каждого места поиска среда CLR сначала попытается найти точное соответствие для требуемой версии сборки. Если идеальное соответствие не найдено, но допустим диапазон версий, среда CLR попытается выполнить сопоставление с другими версиями до сбоя.

Модификатор внутреннего доступа

Когда классы объявляются открытыми, они могут использоваться другими классами в той же сборке или любой другой сборке. Модификатор внутреннего доступа изменяет это поведение, чтобы ограничить использование класса другими классами в той же сборке. Классы в других сборках не знают о наличии элементов, помеченных как внутренние.

Модификатор внутреннего доступа может применяться к элементам классов, таким как методы и свойства. Это позволяет скрывать отдельные элементы от классов в других сборках. В этом случае можно создать экземпляр открытого класса из другой сборки, но будут доступны только открытые члены этого класса, а не те, которые помечены как внутренние.

public class InternalExample
{
    public void ThisIsVisibleToOtherAssemblies() { }
    internal void ThisIsInvisibleToOtherAssemblies() { }
}

Примечание: если модификатор доступа не предусмотрен при объявлении класса, видимость по умолчанию является внутренней.

protected internal

Поведение модификатора внутреннего доступа для членов класса может быть изменено с помощью protected internal. Методы и свойства, помеченные как protected internal, скрыты от других сборок, за исключением тех случаев, когда класс является производным от рассматриваемого класса. Для производных классов в других сборках внутренние методы по-прежнему скрыты, но защищенные внутренние методы видны. Наследование и производные классы рассматриваются в следующей части учебника по объектно-ориентированному программированию на языке C#.
статьи IT, си шарп, ООП