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

Question

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

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

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

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

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

Спасибо.

Answer 1

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

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

Способ обойти это:

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

По сути, перенаправление привязки говорит: «Если вы ищете DLL с номерами версий в диапазоне от 1.x до 1.y, вместо этого посмотрите на версию 1.z».

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

Answer 2

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

[AssemblyVersion]

и

[AssemblyFileVersion]

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

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

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

Answer 3

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

Answer 4

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