Как бороться с выпущенными общими библиотеками в .NET? - PullRequest
Новая
       19

Как бороться с выпущенными общими библиотеками в .NET?

4 голосов
/ 28 февраля 2012

Это структура SVN: 

/trunk
    + ProjectA
    + ProjectB
    + Common
        + ProjectCore
        + References

ProjectA и ProjectB доставят конечный продукт, и у каждого из них может быть свой жизненный цикл выпуска.Оба проекта используют одни и те же общие библиотеки из ProjectCore.ProjectCore также будет иметь собственный жизненный цикл выпуска.В ProjectA и ProjectB мы хотим сослаться на библиотеки ProjectCore.ProjectCore-libs были добавлены в SVN после успешного жизненного цикла релиза ProjectCore.ProjectCore-libs добавляются в папку References.

Этим мы выпускаем (замораживаем) наши сборки ProjectCore как компонент, который был полностью протестирован.Итак, у нас есть несколько выпусков Core-lib:

  • RLS_Core_1.00
  • RLS_Core_1.01
  • RLS_Core_2.00
  • RLS_Core_3.00

Так как мы добавляем освобожденные библиотеки (dll's) в SVN, ProjectA и ProjectB могут ссылаться на них.Каков наилучший подход для этого?

Подход 1

Добавьте ProjectCore -libs в SVN в новую папку под References с именем RLS_Core_X_XX,

В решении ProjectA и ProjectB мы добавляем ссылку на эту уникальную папку: ./trunk/Common/References/RLS_Core_X_XX.

Подход 2

Добавьте ProjectCore -libs в SVN в одну и ту же папку References/Core.Если в нем была «старая» версия, это будет коммит.

В решении ProjectA и ProjectB мы добавляем ссылку на: ./trunk/Common/References/Core.Мы используем внешние свойства SVN, чтобы определить, какая версия Core-libs должна использоваться для ProjectA и ProjectB.

. В обоих подходах разработчику явно необходимо решить, какую версию Core-libs он хочет получить.использовать в своем проекте союзы.Правило не изменяет Core-libs, если вам не нужно обновляться из-за отсутствия функциональности. Подход 1 : редактировать в проекте решения. Подход 2 : редактировать во внешних свойствах.

Какой подход предпочтительнее?

Ответы [ 4 ]

1 голос
/ 28 февраля 2012

Первое, что может показаться естественным, - это использовать рекомендованную структуру папок (branches, tags, trunk) для каждого проекта отдельно . Это относится и к обычному проекту, особенно если вы собираетесь использовать релизы, на которые ссылаются эти два конечных продукта. Поскольку эти проекты будут разрабатываться отдельно, вы сможете создавать отдельные теги и ветви.

Как только вы это сделаете (и поскольку вам необходимо включить все ссылки в виде сборок), было бы неплохо скопировать выпущенные сборки в подпапку каждого проекта Reference отдельно.

Таким образом, всякий раз, когда вы создаете ветку, у вас есть точный снимок нужной версии, и он не зависит от разработки общих вещей.

Другими словами: 

/RepoRoot
    + ProjectA
        + branches
        + tags
            + v1.0
            + v1.1
        + trunk
            + references (includes 3rd-party and ProjectCore)
    + ProjectB
        + branches
        + tags
            + v0.8
            + v1.2
        + trunk
            + references
    + ProjectCore
        + branches
        + tags
            + v2.0
            + v2.1
        + trunk
            + references
0 голосов
/ 28 февраля 2012

Как уже говорили другие, все совершенно одинаково, и это должно быть хорошо задокументировано. Но я бы порекомендовал размещать выпуски ProjectCore не в виде подпапки с именем версии папки ствола. Вместо этого я бы создавал ветки для каждого выпуска, чтобы в ProjectCore вы получали такую ​​структуру: 

/RepoRoot
   + ProjectCore
   + trunk
       + ProjectCore
   + branches
       + RLS_Core_1_00
       + RLS_Core_1_01
       + RLS_Core_2_00
   + ProjectA
       + trunk
           + ProjectA
       + branches
           + ProjectA_3_57
           + ProjectA_3_78

Если вы связываете в ProjectA с ProjectCore, используя внешнюю папку под ProjectA, которая ссылается на конкретную ветку ProjectCore, или если вы изменяете путь ссылки в файле .csproj, идущий вне структуры папок ProjectA (на уровень выше) для ссылки - дело вкуса.

Я бы зависел от этого ответа от того, насколько хорошо разработчики знакомы с функцией внешнего свойства subversion. Если большинство из них не знают этого или как именно это работает, это приведет их в замешательство и приведет к ошибкам. В этом случае используйте прямой подход, поместив путь в файл .csproj. Если каждый разработчик знает и использует внешние компоненты, возьмите это.

0 голосов
/ 28 февраля 2012

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

Итак, я бы сделал это явно - решение 1 - со ссылкой на каталог с именем версии lib в нем.и не пытайтесь повторно использовать один и тот же каталог ссылок.Тогда вы будете знать, какой набор DLL доставить, и вы не ошибетесь.(что вы могли бы сделать, если вы обновили свой проект без опции 'use externals', некоторые люди делают это. В .NET, если вы случайно перестроили с 'неправильными' dll, вы окажетесь в мире эталонного ада).

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

0 голосов
/ 28 февраля 2012

Мне нравится Подход 1, так как он должен быть быстрее и проще переключаться между различными версиями

...