Как использовать ресурсы, разделяемые между проектами

Question

Мы используем Team Foundation Server и имеем множество проектов веб-приложений ASP.NET. Каждое из веб-приложений использует собственную систему управления контентом, которую мы разработали в доме. CMS сама по себе, веб-приложение ASP.NET.

При развертывании CMS находится в подкаталоге, например «/ Admin». CMS состоит из файлов .aspx и ascx, и соответствующие сборки, конечно же, помещаются в корзину.

В настоящее время файлы CMS существуют отдельно для каждого веб-приложения в источнике управления. Другими словами, папка «Админ» существует в каждом веб-приложении, которое зависит от CMS. Это создает очевидные проблемы, поскольку обновления CMS должны распространяться на каждый зависимый сайт. Моя задача - автоматизировать/упростить процесс.

В настоящее время мы не производим никаких автоматических сборок. У меня ограниченное знание ветвления управления версиями в TFS, и я не уверен, что он применим в этом сценарии. Каков наилучший способ обеспечить, чтобы зависимые проекты получали последние сборки и разметку из проекта CMS? Заранее спасибо.

Похоже, что № 2 (от бамбука) - это решение, которое мне нужно. Учитывая, что общий код уже находится в каждом отдельном проекте, можете ли вы вкратце описать процесс, который я рассмотрю, чтобы «Разделить/Разделить» CMS? Кроме того, стоит отметить, что я не хочу, чтобы файлы .cs распространялись на зависимые проекты, а именно разметки и сборки. Это изменяет стратегию? Должен ли я сначала создать событие сборки в общем проекте для копирования необходимых файлов в папку «Отпуск», а затем развернуть папку «Отпуск»?

Answer 1

Это пара популярных способов решения этого сценария.

1. Содержит проект TFS для общего материала в каждой рабочей области приложений, а затем включает совместно используемый проект в каждом приложении. Используйте этот метод, если вы хотите, чтобы все команды/приложения получили общие изменения сразу же после их сборки, так как они также получат последнюю информацию из общего материала.

2. Отрасль/Совместное использование общих материалов в каждом дереве управления источником приложений. Это легко сделать в TFS. Это действительно хорошо, если каждая команда/приложение хочет контролировать, когда они получают последнюю из общих вещей. Это позволяет командам выполнять свою задачу до тех пор, пока они не будут готовы интегрировать общий материал.

Обычно я предпочитаю # 2. Но это действительно зависит от особенностей того, как вам нужно/нужно работать.

Answer 2

Не уверен в TFS, но в большинстве систем управления версиями вы можете обмениваться кодами через несколько местоположений. Изменения в любой общей копии отражаются на всех. На уровне Visual Studio они будут отображаться как независимые фрагменты кода.

Каждое из ваших веб-приложений (решений) содержит проект, который полностью состоит из общего кода. Обычно исходный код является общим и становится частью процесса сборки. Вы можете поделиться полученной DLL, но большинство людей не контролируют DLL.

Если у вас нет источника для общих частей, вероятно, установка кода в GAC станет вашим единственным вариантом для создания общей части.

Answer 3

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

Затем вам нужно добавить ссылочный путь к сборке xml, чтобы ваш сервер TFS знал, где находится .dll. Каждый раз, когда для проекта выполняется новая сборка, он копирует самую последнюю версию совместного использования в bin для проекта.

Все наши проекты, включая Shared, имеют 4 филиала: разработка, интеграция, постановка и производство. Поэтому, когда нам нужно внести изменения в нашу общую библиотеку, и мы делаем это в своей ветке развития, потому что она изолирована. Как только мы будем счастливы, мы объединим наши изменения в интеграцию. Мы строим общую интеграцию, а затем мы строим, на какие изменения затронуты проекты. Это когда мы начинаем тестировать другие приложения, чтобы узнать, вызвали ли наши изменения какие-либо ошибки. Так что ...

1. Одно место, чтобы сделать наши изменения в общей библиотеке
2. Присоединения к одной ветви, а не несколько филиалов в каждом проекте.
3. Использование общего доступа так же просто, как добавление ссылки
4. Один проект и версия Shared могут быть перенесены из разработки в производство без ущерба для каких-либо других проектов. Версия .dll Shared копируется в папку bin проектов. Как только изменения в другом проекте выполняются, он получит самую последнюю версию, когда ее проталкивают через ее ветви.