Найдите сборку GAC, если изменился только номер сборки или редакции

1

У меня вопрос о том, как CLR обрабатывает сборку и загрузку сборки из GAC, если изменены номера сборки и ревизии. Сборка состоит из четырех частей [Major]. [Minor]. [Build]. [Редакция]. Я знаю, что если майор и майор изменены, вам нужна политика издателя, чтобы найти новую версию сборки из GAC. Что делать, если изменить только номер сборки или ревизии? В моем сценарии ниже он не работает с обновлениями сборки и обновления.

В моем приложении у меня есть информация о сборке как [1.0. *], Поэтому TFS строит сборку с [1.0.5414.23455] номерами поэтапно на каждой сборке. Каждый день TFS строит проект и генерирует сборку с добавочными номерами Build и Revision. Это ожидаемое поведение, поскольку я указал wild card [1.0. *] В файле AssemblyInfo.

Теперь у меня есть клиентское приложение, которое создано против моей версии приложения [1.0.5414.23455]. Я использую приложение для установки в GAC. Теперь клиентское приложение отлично работает, если GAC имеет версию сборки приложений [1.0.5414.23455], но если я установлю более новую версию (технически ничего не изменилось, просто новая ночная сборка) [1.0.5414.23456] в GAC, клиентское приложение не загрузит эту новую версию,

Я имел в виду некоторые блоги/документы Microsoft и обнаружил, что до тех пор, пока номера Major и Minor одинаковы, клиентское приложение должно иметь возможность загружать сборку из GAC. Строки сборки и ревизии не являются обязательной проверкой при поиске сборки из GAC.

Правильно ли, что изменения сборки и изменения номера не влияют на поиск сборки из GAC?

Заранее спасибо.

  • 0
    Как вы называете свою сборку?
  • 0
    С файлом ключей строгого имени и стандартным способом назначения через свойства Visual Studio.
Показать ещё 1 комментарий
Теги:
.net-assembly
versioning
gac

1 ответ

0

Чтобы избежать компиляции сложностей с новыми версиями компонентов, развернутых в GAC, вы можете использовать bindingRedirect в вашем web.config или app.config, например:

 <runtime>
    <generatePublisherEvidence enabled="false" />
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
    <dependentAssembly>
        <assemblyIdentity name="MyComponent.Web.UI" publicKeyToken="121fae78165ba3d4" />
        <bindingRedirect oldVersion="1.0.5414.23455" newVersion="1.0.5414.23455" />
      </dependentAssembly> ...

Обратите внимание, что атрибут oldVersion представляет также диапазон версий для замены oldVersion="1.0.0.35-1.0.1016.35" а атрибут newVersion означает замену версии newVersion="2.0.1205.35"

По вашему вопросу, зачем нам нужен bindingRedirect?

Зависимости сборки являются частью метаданных сборки, и вы можете увидеть это, используя что-то, называемое gacutil (это часть инструмента.NET SDK Tools) или как я это сделал ниже, используя.NET Reflector. Поскольку ссылки и их версии являются частью сборок, для ссылки на новую версию требуется компиляция или изменение ссылки app.config.

Изображение 174551

  • 0
    Да, я знаю об этом, и я упомянул политику издателя abt в моем вопросе. Я специально хотел знать, что изменения в Build и номере ревизии вызывают ошибку при загрузке сборки GAC.
  • 0
    Скорее всего, вы не компилируете все компоненты для новой версии, что может привести к расхождениям
Показать ещё 4 комментария

Ещё вопросы

Сообщество Overcoder
Наверх
Меню