Кто должен установить разделяемую библиотеку .NET в GAC? Структура, которая обеспечивает библиотеку? Каждое приложение, которое использует это? И то и другое? - PullRequest
Новая
       17

Кто должен установить разделяемую библиотеку .NET в GAC? Структура, которая обеспечивает библиотеку? Каждое приложение, которое использует это? И то и другое?

2 голосов
/ 05 мая 2009

Возможно, это скорее философский вопрос.

Допустим, у меня есть какая-то платформа, и я решил предоставить библиотеку .NET, которая облегчает использование определенных аспектов этой платформы. Я не хочу, чтобы каждое приложение, которое использует платформу, носило копию библиотеки локально, поэтому я хочу, чтобы она была в GAC (даже со всеми проблемами обслуживания, которые это может подразумевать.)

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

Однако, если каждое приложение также устанавливает библиотеку в GAC, начинается подсчет ссылок установщика Windows, и моей среде больше не нужно беспокоиться о переносе старых библиотек в сценарии обновления. Используемая библиотека будет удалена, только если последняя ссылка на установщик Windows исчезнет.

Очевидно, что каждое приложение имеет доступ к библиотеке во время сборки приложения и может легко включить ее в установщик.

Кто-нибудь имеет мнение / точку зрения / опыт одного против другого? Я понимаю, что это не совсем требуемый тип вопроса (поскольку он вызывает обсуждение), но я думаю, что было бы полезно короткое обсуждение.

Ответы [ 2 ]

1 голос
/ 05 мая 2009

У нас также есть точная потребность в нескольких продуктах, и для нашей платформы мы просто используем модуль слияния MSI , на который ссылается каждый продукт. 

<Feature ...>
  ...
  <MergeRef Id="FrameworkMergeModule" />
</Feature>
...
<Directory ...>
  <Merge Id="FrameworkMergeModule" SourceFile="..\Tools\Framework.msm" ... />
</Directory>

Не нашли проблем с этим подходом, как вы сказали, подсчет ссылок делает свое дело.

Есть дополнительные обходы, через которые можно перейти к сборкам в GAC (сильное именование, немного больше работы в wix), но ничего особенного. Этот подход работает, если вы используете GAC или просто делаете обычное развертывание xcopy в каталоге установки (через wix-fu)

Основная проблема, которую мы испытывали (после строгого присвоения имени сборке), заключалась в том, что мы не понимали атрибуты AssemblyVersion и AssemblyFileVersion полностью перед погружением ... вы действительно хотите изменять AssemblyVersion только тогда, когда это действительно необходимо, и смотреть на подстановочные ссылки Создание и / или ревизия версий для упрощения работы (при условии, что у вас есть дисциплинированная стратегия управления версиями)

0 голосов
/ 28 мая 2009

Является ли каждая новая версия вашего фреймворка обратно совместимой? Вы когда-нибудь осуждали компоненты или меняли интерфейсы?

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

Вот SO вопросы о создании файлов политики

MS документация по файлам политики издателя

Следующее действие заставит любое приложение, ссылающееся на 1.0.0.0, использовать более новую версию 2.0.0.0. Я считаю, что вы также можете использовать подстановочные знаки. 

<configuration>
    <runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
            <dependentAssembly>
                <assemblyIdentity name="myAssembly"
                       publicKeyToken="32ab4ba45e0a69a1"
                       culture="en-us" />
                <!-- Redirecting to version 2.0.0.0 of the assembly. -->
                <bindingRedirect oldVersion="1.0.0.0"
                      newVersion="2.0.0.0"/>
            </dependentAssembly>
        </assemblyBinding>
    </runtime>
</configuration>
...