поддержание сборок библиотеки классов, используемых несколькими проектами

Question

Хорошо, вот сценарий.

В проекте A разработана библиотека классов (назовем ее MyLib). Я выпускаю проект A (в домашнем проекте) с версией 1 MyLib.

Я начинаю разработку для проекта B, но расширяю MyLib до версии 2, включая несколько оптимизаций для существующих типов.

Если я выпущу Mylib 2 как для проекта A, так и для проекта B, мне придется перекомпилировать проект A для поддержки изменений типов, есть ли у кого-нибудь решения для этого, которые проверены и верны?

Answer 1

Вы можете попробовать перенаправление сборки , и Project A загрузит более новую версию вашей библиотеки. Для этого потребуется добавить информацию о перенаправлении в конфигурацию всех машин, на которых запущено приложение, но вам не придется перекомпилировать. Вы можете сделать это в файле конфигурации приложения или на уровне компьютера.

Пример из этой статьи, как будет выглядеть файл:

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

Конечно, если вы нарушили совместимость с вашей исходной библиотекой в ​​новой версии, это не сработает.

Answer 2

Дайте MyLib строгое имя и установите его в GAC . GAC может иметь несколько версий одной и той же сборки. Для этого потребуется дать строгое имя версии 1 MyLib (а не только версии 2).

Проект A хочет версию 1 MyLib и находит ее в GAC. Проект B хочет версию 2 MyLib и находит ее в GAC. Все счастливы, и вам не нужно хранить 30 копий разных версий MyLib в одних и тех же каталогах сборок, которые их используют, воссоздающих DLL-ад.

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

Answer 3

Если вам не нравится перенаправление направления сборки @ Steven и предполагается, что вы не хотите перекомпилировать Project A, вы можете просто развернуть различные версии MyLib для каждого проекта в частном порядке.
Проект А тогда просто продолжит использовать версию 1, а Проект Б будет использовать версию 2. Кажется, это то, что вы хотите услышать - и это тривиально. Либо поместите MyLib dll в папку (или подпапку) каждого проекта, и каждый проект автоматически выберет соответствующую локальную версию, либо вы можете строго назвать их в GAC, и каждый проект получит конкретную версию, с которой вы скомпилировали. Это на самом деле поведение по умолчанию, и вам не нужно делать ничего сложного, чтобы достичь этого.

Answer 4

Мое предложение: непрерывная интеграция.

Используя такой инструмент, как CruiseControl.NET, вы можете выполнить перестройку каждого существующего проекта / решения, даже получить выходные данные одного (.dll), загруженного в Source COntrol для использования в других проектах, чтобы каждый раз запускать модульные тесты время, чтобы вы могли проверить, не добавляют ли дополнения / изменения в проекте, используемом в решении A, решение B, также использующее этот проект. Вы можете установить автоматическую сборку каждую ночь или запустить ее вручную из приложения CruiseControl.NET systray.

Answer 5

Я бы поместил весь свой код в систему контроля версий, такую ​​как Subversion (использование веток и тегов), и автоматизировал процесс сборки. Я использую FinalBuilder .

Поскольку у вас есть контроль над библиотекой, я бы рекомендовал шаблон ветвей выпуска .

Answer 6

Ваш вопрос довольно общий. Что вы хотите достичь? Должен ли Project A использовать версию 2 вашей библиотеки или старую версию?

Если A должен использовать версию 1, то сильное именование или приватное развертывание должны решить вашу проблему. Но я думаю, что тогда вы бы не задали вопрос.

Если А должен использовать версию 2, то решение зависит от ваших изменений. Если интерфейс сборки не изменился (а только внутренние алгоритмы), то A должен работать с V2 без перекомпиляции. Если интерфейс изменился, вам все равно придется настроить проект А, и не может быть общего решения.

Чтобы сохранить необходимые изменения небольшими, управляемость - это вопрос хорошего дизайна объекта / интерфейса. Но на то, как это сделать, невозможно ответить без подробностей о ваших объектах и ​​необходимых изменениях.

Answer 7

Вот еще один вариант, хотя сначала вы должны серьезно рассмотреть другие варианты.

ProjectA ссылается на MyLib.dll, которая является версией 1.

Настройте выходное имя проекта MyLib для создания «MyLib.2.dll». (Вы также можете создать новый проект, но это звучит как перебор.)

Перестройте MyLib и ProjectB. ProjectB теперь будет ссылаться на MyLib.2.dll, оставляя ProjectA и MyLib.dll совершенно без изменений.