Структура проекта TFS усложняет простые вещи

Question

Моя команда в настоящее время работает над веб-сайтом ASP .NET. Мы являемся одной из первых групп в нашей организации, которая использует TFS2008 для контроля версий. Когда я присоединился к проекту, он уже был активным в течение нескольких месяцев. Ниже приведена схема базовой файловой структуры, которую мы используем в TFS:

$/TfsProject/
|
|   /* Contains our in-house class libraries. */
|-- Common/
|   |
|   |-- Extensions/
|   |   |-- Extensions.csproj
|   |
|   |-- Loggers/
|       |-- Loggers.csproj
|
|   /* Contains third-party libraries. */
|-- Library/
|   |
|   |-- EnterpriseLibrary/
|       |
|       |-- v4.1/
|           |-- Microsoft.Practices.EnterpriseLibrary.Common.dll
|
|   /* Contains the website itself. */
|-- Site/
    |
    |-- Packages/
    |   |-- Packages.csproj
    |
    |-- Website.root/
        |
        |-- Website/
            |-- Website.sln
            |
            |-- Website/
            |   |-- Website.csproj
            |   |-- Default.aspx
            |
            |-- WebsiteUnitTests/
            |   |-- WebsiteUnitTests.csproj
            |
            |-- WebsiteWebControls/
            |   |-- WebsiteWebControls.csproj
            |
            |-- Utilities/
                |-- Utilities.csproj

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

Есть ли простой способ реализовать это, основываясь на нашей нынешней иерархии? Я прочитал руководство TFS Patterns & Practices , но реализация любых его предложений потребует значительных изменений (а также обновления всех наших проектов и решений). Кроме того, наша организация ожидает выпуска TFS2010, прежде чем включить Team Builds - поэтому они нам недоступны.

Answer 1

Более «переносимым» решением было бы иметь сборку специально для общих проектов / решений. Последний шаг этих сборок состоит в том, чтобы зарегистрировать двоичные файлы в папке публикации (возможно, в / библиотеки). Когда вы получаете последние версии для клиентских проектов (те, которые ссылаются на двоичные файлы), вы в конечном итоге снесете последние двоичные файлы. Вы не теряете возможность ветвить клиентские проекты, и члены команды могут свободно отображать папки по своему выбору.

Я скажу в целом, вы должны пересмотреть структуру вашей папки. Это не учитывает очень гибкую структуру ветвления. Вы, похоже, используете свой TFS-репозиторий так же, как исторически многие пользователи VSS: как файловая система с версиями.

Answer 2

• Решение, которое может работать, - это иметь проекты в общем все выводят на тот же каталог ("C: \ temp \ dlls"), вместо каждой локальной папки / bin.

• Этот каталог может быть добавлен в решение веб-проекта. Все ссылки на DLLS должны быть сделаны в общую папку, извлеченную из TFS.

• Этот каталог можно добавить в TFS как папка. Все в команде будут должны быть сопоставлены папки локально с тем же относительным путем к файлу решения.

• Место, где "минимальные усилия" кусок ломается в том что файлы должны быть проверены в / из когда скомпилирован. Остальная часть команды будет тогда придется GetLatest. GetLatest требование может быть на самом деле лучше, потому что вы не хотите принудительных изменений вам, пока вы находитесь в середине развивается.

В итоге у вас есть папка с скомпилированными dll, добавленными в решение веб-проекта. Это также та же папка, в которую собраны все общие библиотеки DLL. В этой папке все проекты в веб-решении ссылаются на Common Dlls. Когда кто-то перестраивает, он должен проверить dll в папке, собрать и затем вернуться обратно. Когда разработчик хочет получить последнюю версию, он вызывает GetLatest для папки и перестраивает свои проекты.

Это на самом деле работало для нас в подобной ситуации, когда мы собирали dll для справки. Разница для нас заключается в том, что скомпилированные dll-файлы так редко встречаются, что вся парадигма «GetLatest» так и не вступила в игру.