Какова лучшая практика для совместного использования Проекта Visual Studio (блок) среди решений
Вы пробовали
camelCaseString =~ /(Image)(Wide|Narrow)(Nice|Ugly)/
?
6 ответов
Поскольку вы упомянули SVN, вы можете использовать внешние для «импорта» проекта фреймворка в рабочую копию каждого решения, которое его использует. Это приведет к такой схеме:
C:\Projects
MyFramework
MyFramework.csproj
<MyFramework files>
SolutionA
SolutionA.sln
ProjectA1
<ProjectA1 files>
MyFramework <-- this is a svn:externals definition to "import" MyFramework
MyFramework.csproj
<MyFramework files>
С этим решением у вас будет исходный код MyFramework, доступный в каждом решении, которое его использует. Преимущество состоит в том, что вы можете изменить исходный код MyFramework из каждого из этих решений (без необходимости переключаться на другой проект).
НО : в то же время это также огромный недостаток, поскольку это позволяет очень легко сломать MyFramwork для некоторых решений при изменении его для другого.
По этой причине я недавно отказался от этого подхода и теперь рассматриваю наши проекты фреймворка как полностью отдельное решение / продукт (с их собственным выпуском - график). Все другие решения затем включают конкретную версию двоичных файлов проектов инфраструктуры.
Это гарантирует, что изменение, внесенное в библиотеки инфраструктуры, не нарушит работу какого-либо решения, которое повторно использует библиотеку. Теперь для каждого решения я могу решить, когда мне нужно выполнить обновление до более новой версии библиотек фреймворка.
Звучит как катастрофа ... как вы справляетесь с разработчиками, которые отменяют / нарушают работу других ...
На вашем месте я бы полностью включил MyFrameWork отдельное решение. Когда разработчик хочет разработать один из 12 проектов, он открывает это проектное решение в одной среде IDE и открывает MyFrameWork в отдельной среде IDE.
Если вы строго назовете его MyFramework Assemby и GAC и будете ссылаться на него в других проектах, тогда «Копирование библиотек DLL» не будет проблемой.
Вы просто создаете MyFrameWork (и событие PostBuild может запустить GacUtil, чтобы поместить его в кэш сборки), а затем выполните сборку другого проекта.
"Лучший способ" будет зависеть от вашей среды. Я работал в среде непрерывной интеграции на основе TFS, где ночная сборка развертывала двоичные файлы в общую папку. Все зависимые проекты отнесены к доле. Когда это стало медленным, я создал несколько инструментов, позволяющих разработчикам иметь локальную копию общих двоичных файлов без изменения файлов проекта.
Работает ли какое-либо из 12 решений, регулярно ли требуются изменения в коде «фреймворка»?
Если да, то ваш фреймворк, вероятно, новый и только что создается, поэтому я бы просто добавил рамочный проект во всех решениях. В конце концов, если работа требует изменения кода фреймворка, это должно быть легко.
Поскольку изменения в фреймворке, сделанные из одного решения, повлияют на все другие решения, произойдут сбои, и у вас будут разобраться с ними.
Если вам редко приходится менять фреймворк при работе с решениями (это должно быть вашей целью), я бы вместо этого включил ссылку на DLL фреймворка и обновлял DLL в каждом решении только по мере необходимости.
svn: externals позаботится об этом хорошо, если вы будете следовать нескольким правилам.
Во-первых, это безопаснее, если вы используйте относительные URI (начинающиеся с символа ^) для определений svn: externals и, если возможно, поместите проекты в тот же репозиторий. Таким образом, определения останутся действительными, даже если сервер Subversion будет перемещен на новый URL.
Во-вторых, убедитесь, что вы следуете следующему совету из книги SVN. Используйте PEG-REV в ваших определениях svn: externals, чтобы избежать случайного сбоя и нестабильных тегов:
Вам следует серьезно подумать об использовании явные номера ревизий во всех ваши внешние определения . Делать это означает, что вы сами решаете, когда снимите другой снимок внешняя информация, а именно какой снимок вытащить. Кроме избегая неожиданности получения изменения в сторонних репозиториях что у вас может не быть никакого контроля над, используя явные номера ревизий также означает, что когда вы задним числом рабочая копия к предыдущей ревизии, ваши внешние определения также будут вернуться к тому, как они выглядели в том предыдущая версия ...
Я согласен с другим автором - это похоже на проблему. Но если вы не можете захотеть сделать это «правильно», я могу придумать два других способа сделать это. Мы использовали что-то похожее на номер 1 ниже. (для собственного приложения C ++)
сценарий, пакетный файл или другой запущенный процесс, выполняющий получение и построение зависимости. (только один раз) Создается / выполняется только в том случае, если в репо нет изменений. Вам нужно будет знать, какой тег / ветку / версию получить. Вы можете использовать bat-файл в качестве этапа предварительной сборки в файлах проекта.
Хранить двоичные файлы в репо (не лучшая идея). Даже в этом случае зависимые проекты должны получить и знать, какую версию получить.
В конце концов, то, что мы пытались сделать для наших проектов, было имитировать то, как мы используем и ссылаемся на сторонние библиотеки.
Что вы можете сделать, так это создать пакет выпуска для зависимости, который устанавливает для себя переменную env пути. Я бы позволил нескольким версиям существовать на машине, а затем зависимые проекты связывают / ссылаются на конкретные версии.
Что-то вроде
$(PROJ_A_ROOT) = c:\mystuff\libraryA
$(PROJ_A_VER_X) = %PROJ_A_ROOT%\VER_X
, а затем укажите нужную версию в зависимых решениях либо по конкретному имени, либо с использованием версии env var.
Не очень красиво, но работает.