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

Question

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

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

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

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

Answer 1

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

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

Answer 2

Вы можете попробовать assembly redirection и иметь проект 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 3

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

Answer 4

Дайте MyLib a strong name и install it to the GAC. GAC может иметь несколько версий одной и той же сборки. Это потребовало бы дать сильное имя версии 1 MyLib (а не только версии 2).

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

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

Answer 5

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

ProjectA ссылается MyLib.dll, который случается быть версии 1.

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

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

Answer 6

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

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

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

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

Answer 7

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

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