Обновление библиотеки DLL в GAC
У меня есть библиотека DLL API, на которую ссылаются несколько сторонних приложений.
Некоторые из этих приложений хотят получить обновления двумя способами. 1) я хочу самые последние вещи 2) не обновляйте мои прямые двоичные файлы так часто
Была мысль о перемещении библиотеки DLL в GAC и написании другой библиотеки DLL, которая является просто оболочкой для библиотеки DLL в GAC (на которую будут ссылаться сторонние приложения). Это позволяет бизнес-логике (той части, которая часто меняется) быть обновляться в GAC и DLL-оболочке потребуется только тогда, когда будут доступны новые функции.
GAC предназначен для хранения версионных библиотек DLL. Таким образом, библиотека DLL-оболочки будет иметь ссылку на конкретную версию библиотеки DLL API. Насколько сложно обновить библиотеку DLL GAC, чтобы ссылки на нее не прерывались, но двоичное содержимое отличалось?
Это так же просто, как не изменять версии DLL GAC при обновлении?
Спасибо.
4 ответа:
Можно создать обновленную сборку, подписать ее и отправить в GAC, чтобы приложения, ссылающиеся на эту сборку, не заметили разницы. Вы должны указать все части номера версии (т. е. иметь номер версии 1.2.3.4, а не 1.2.3.* в AasemblyInfo.cs file) и использовать тот же ключ sn. Тогда ссылка на конкретную версию не будет нарушена. И вы сможете обновить свою библиотеку DLL по мере необходимости.
Насколько сложно обновить библиотеку DLL GAC, чтобы ссылки на нее не прерывались, но двоичное содержимое отличалось?
Вы не можете сделать это напрямую. В GAC можно поместить только подписанные библиотеки DLL. При построении приложения на основе подписанной библиотеки DLL компилятор берет хэш содержимого библиотеки DLL и помещает его в приложение. Когда среда выполнения .NET загружает приложение,она проверяет этот хэш на соответствие реальной копии библиотеки DLL. Если эта библиотека DLL не совпадает с той, с которой вы построили, .NET выдает исключение.
Чтобы обойти это, нужно:
- создайте схему нумерации версий для библиотеки DLL GAC. Это может быть так же просто, как всегда увеличивать номер версии при выполнении сборки.
- в вашем приложении.config, добавьте a
<bindingRedirect>
элементФактически перенаправление привязки говорит: "Если вы ищете DLL с номерами версий в диапазоне 1.x - 1.y, посмотрите на версию 1.z вместо этого".
Редактировать: есть способы вокруг проверки целостности строгих имен .NET , но я рекомендую разрабатывать приложение вокруг стандартного механизма строгих имен, прежде чем пытаться обойти его.
Я использую установщик Windows для развертывания моих сборок в GAC. С точки зрения обслуживания важно понимать разницу между:
[AssemblyVersion]
И
[AssemblyFileVersion]
Первое рассматривается как часть контракта / привязки строгого имени, в то время как второе-нет. Кроме того, последнее рассматривается установщиком Windows с точки зрения принятия решения о перезаписи файла или нет во время обновления.
Линия Боттона: если ваш изменения в сборке не нарушают интерфейсы и не вызывают регрессии поведения, вы можете сохранить AssemblyVersion тем же самым и увеличить AssemblyFileVersion и повторно развернуть.
Именно так работают пакеты обновления .NET Framework, поскольку Microsoft должна иметь возможность обслуживать библиотеки базовых классов, не нарушая приложения, имеющие существующие ссылки на SN.
Ссылки могут включать информацию о версии или ссылаться на любую доступную версию. Это определяется автором приложения, которое ссылается на вашу библиотеку DLL. Конечно, вы можете отправить обновленную DLL как имеющую ту же версию, что и в GAC, но весь смысл управления версиями состоит в том, чтобы позволить всем сторонам корректно обрабатывать обновления. Так что вам, возможно, придется усовершенствовать свою задачу.