Тема 2. Модульное программирование в среде .Net
Проблема управления версиями DLL-библиотек и ее решение
Использование Dll-библиотек при разработке приложений под ОС Windows сильно облегчило работу команд программистов. Однако это привело к возникновению новой проблемы, которая в последствии получила название DLL-hell или DLL-hell.
Суть этой проблемы заключается в конфликте версий DLL, призванных поддерживать определённые функции. По исходному замыслу, DLL должны быть совместимыми от версии к версии. Однако оказалось, что несовместимость от версии к версии является правилом, а не исключением. Проблема постоянно повторяется, когда программу пытаются запустить не с той DLL, с которой она тестировалась.
Как правило при разработке не применялись какие то правила по именованию, версии, положению Dll-библиотек в файловой системе, что приводило к тому что несовместимые DLL библиотеки замещали друг друга.
Аналогична проблема возникала и в Mac OS X, а также в ОС Unix (Linux и пр.). Данная проблема носит название Dependency hell. Однако там она встречается только в случае пренебрежения пользователем встроенной в ОС системой управления пакетами.
Во избежание конфликтов обычно используют множество избыточных копий DLL для каждого приложения, что сводит на нет исходную идею получения преимущества от DLL как стандартных модулей, хранящихся один раз в памяти и разделяемых многими задачами. Кроме того, при таком опыте после исправления ошибок в DLL или восстановления системы из архива количество различных DLL, носящих одно и то же имя и выполняющих те же функции, возрастает, а автоматическое обновление версии или исправление ошибок становится невозможным.
В качестве решения данной проблемы, при разработки платформы .NET Framework компания Майкрософт, предложила использовать сборки (assemblie), которые в затем помещаются в специальное защищенное хранилище сборок (Global Assembly Cache, GAC). При таком подходе в сборку, которая может разрабатываться отдельно от использующего её приложения, кроме IL кода, включается информация о содержимом сборки, так называемые метаданные.
Метаданные — это обязательный компонент, каждый CIL-совместимый компилятор должен их генерировать. Метаданные важны потому, что CLR нужна возможность определять, какие типы присутствуют в каждом из загружаемых ею управляемых модулей. Но эта возможность важна также для компиляторов и других утилит, работающих с управляемыми исполняемыми файлами. Благодаря метаданным, Visual Studio .NET поддерживает IntelliSense — средство, позволяющее отображать контекстно-зависимый список доступных методов и свойств при вводе в редакторе имени экземпляра класса.
Сборки среды .NET. Строго именованные сборки
Сборка — это файл или набор файлов, в совокупности составляющих логическую единицу. В данном контексте термином файлы обозначаются главным образом управляемые модули, но в сборку могут входить и иные файлы. Большинство сборок содержит один файл, но может содержать и иногда содержит несколько файлов.
В состав одного из файлов, входящих в состав сборки входит декларация (manifest), которая содержит в себе информацию о :
Имени сборки;
Списке всех файлов входящих в состав сборки, вместе с хеш-значением, вычисленным от содержимого файлов;
Список типов данных, экспортируемых другими файлами сборки, и информация, связывающая эти типы данных с файлами, где они определены;
Номер версии в формате major.minor.build.revision (например, 1.0.272-2).
Простые приложения обычно представлены сборками состоящими из одного файла (содержащих и манифест и программный модуль и ресурсы).
Моногофайловые сборки лучше всего применять при разработке сложных приложений. В данном случае можно хранить ресурсы приложения можно хранить вне кода, что позволит изменять их без перекомпиляции всего приложения. Также при разделении исполняемого кода на несколько модулей, загрузка модуля в память происходит только при необходимости.
В состав .NET Framework SDK входит утилита AL (Assembly Linker) для объединения файлов в сборки.
Компиляторы могут создавать сборки двух типов:
Нестрого именованные сборки (weakly named). Данный тип сборки указывает на то, что среда CRL для идентификации сборки будет использовать имя сборки, указанное в декларации (представляет собой имя файла сборки без расширения). При использовании данного типа сборок приложением, сборка должна находится в одной директории вместе с использующей её исполняемым файлом;
Строго именованные сборки (strongly named). Данный тип сборки указывает на то, что в состав сборки входит значение электронно-цифровой подписи, и среда CRL для идентификации сборки будет использовать: имя сборки, указанное в декларации; открытый ключ для проверки электронно-цифровой подписи под сборкой; номер версии сборки; а также строка региональных стандартов (если она есть).
Использование электронно-цифровой подписи (которая создается только при использовании закрытого ключа, который доступен только создателю сборки) позволяет создавать сборки, устойчивые к подделкам.
Структура идентификационной строки строго именованной сборки:
Name, Version=1.1.0.0, Culture=neutral, PublicKeyToken=1234567890
где:
Name – имя сборки указанное в декларации;
Version – номер версии сборки в формате Major.Minor.Build.Revision;
Culture – указание о региональной принадлежности;
PublicKeyToken – значение электронно-цифровой подписи.
Пример использования нестрого именованной сборки:
Исходный код нестрого именованной сборки (файл MYFILE.cs), которая содержит используемую функцию MyFunc:
using System;
namespace MyLibrary {
public class MyClass {
public void MyFunc() {
Console.WriteLine("Print by MyFunc()");
}
}
}
Компилируем при помощи компилятора командной строки как dll библиотеку:
c:\ >csc /t:library MYFILE.cs
Исходный код приложения, которое вызывает из нестрого именованной сборки (файл MYFILE.dll) функцию MyFunc:
using System;
using MyLibrary;
class MainClass {
static void Main()
{
var a = new MyClass ();
a. MyFunc();
Console.ReadLine();
}
}
Компиляция приложения, которое использует нестрого именованную сборку MYFILE.dll:
c:\>csc /r:MYFILE.dll main.cs
Примечание:
Ключ /r указывает компилятору что необходимо подключить указанную сборку к приложению;
Нестрого именованная сборка MYFILE.dll, должна находится в одной директории с исполняемым файлом, как во время компиляции, так и во время выполнения.
Глобальное хранилище сборок GAC
Глобальный кэш сборок (global assembly cache, GAC) – глобальный репозитарий сборок, предназначенных для использования разными приложениями. Для занесения в GAC сборка должна:
Скомпилирована как строго именованная сборка.
Иметь цифровую подпись. Использование цифровой подписи затрудняет подмену библиотек.
Иметь определенное значение версии. Допускается хранение в GAC одной и той же библиотеки, но с различными значениями версий.
Для того чтобы поместить сборку в GAC необходимо использовать утилиту gacutil.exe. Данная утилита входит в состав .NET Framework SDK.
Помещение в GAC:
gacutil /i MYFILE.dll
Удаление из GAC:
gacutil /u MYFILE.dll