Обновление DLL в GAC

Question

У меня есть DLL API, с которым ссылается несколько сторонних приложений.

Некоторые из этих приложений нуждаются в вещах двумя способами с точки зрения обновлений. 1) Я хочу, чтобы последние вещи 2) Не обновлять свои прямые двоичные файлы, которые часто

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

GAC предназначен для хранения файлов с версией в формате DLL. Таким образом, DLL-оболочка будет ссылаться на определенную версию DLL API. Насколько сложно обновить DLL GAC, чтобы ссылки на него не ломались, но двоичное содержимое отличается?

Это так же просто, как не изменять версии GAC DLL при обновлении?

Спасибо.

Answer 1

Вы можете создать обновленную сборку, подписать ее и нажать на нее, чтобы приложения, ссылающиеся на эту сборку, не заметили разницы. Вам нужно указать все части номера версии (то есть номер версии как 1.2.3.4, а не 1.2.3. * В файле AasemblyInfo.cs) и использовать ту же клавишу sn. Тогда ссылка на версию не будет нарушена. И вы сможете обновить свою DLL по мере необходимости.

Answer 2

Насколько сложно обновить DLL GAC, чтобы ссылки на него не ломались, но бинарное содержимое отличается?

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

Путь обойти это заключается в следующем:

1. Внедрить в версии схемы нумерации для вашего GAC DLL. Это может быть так же просто, как всегда, увеличивать номер версии при выполнении сборки.
2. В вашем app.config, добавьте <bindingRedirect> элемент

В результате привязки редирект говорит, «если вы ищете DLL с номерами версий в 1.x диапазоне до 1, y, смотрите в версии 1.z вместо ".

Редактировать: Есть ways round the .NET strong name integrity check, но я рекомендую разработать приложение вокруг стандартного сильного механизма имени, прежде чем пытаться его обойти.

Answer 3

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

Answer 4

Я использую установщик Windows для развертывания своих сборок в GAC. С точки зрения обслуживания, важно понимать разницу между:

[AssemblyVersion]

и

[AssemblyFileVersion]

Бывший рассматривается как часть сильного договора имя/связывание в то время как последний нет. Кроме того, последний рассматривается установщиком Windows с точки зрения принятия решения о перезаписи файла или нет во время обновления.

Botton line: Если ваши изменения в сборке не нарушают интерфейсы или не приводят к каким-либо поведенческим регрессиям, вы можете сохранить AssemblyVersion одинаково и увеличивать AssemblyFileVersion и передислоцировать.

Вот как работают пакеты обновления .NET Framework, поскольку Microsoft должна иметь возможность обслуживать библиотеки базового класса, не нарушая приложения, имеющие существующие ссылки на SN.