Могут ли проекты TFS ссылаться друг на друга?

Question

Я недавно начал работать в программной среде предприятия с сотнями различных приложений, все из которых были ограничены собственными «хранилищами».Одна из моих задач - попытаться немного стандартизировать вещи, и первой попыткой будет стандартное ведение журнала событий.В настоящее время «стандарт» компании гласит: «Каждый должен использовать Enterprise Library для регистрации».На самом деле это означает, что разные разработчики, работающие над разными проектами, по-разному реализуют разные журналы и просто большую часть времени используют эту библиотеку.

С этой целью я стремлюсь абстрагироваться от фактическогоинструмент для ведения журнала за внутренним интерфейсом, разработанным компанией как «стандарт компании».Идея состоит в том, чтобы переместить фокус того, что означает «стандарт», из инструмента реализации в сторону его использования.Затем приложения будут использовать внутреннюю библиотеку и не будут заниматься закулисным инструментом (за исключением, возможно, раздела app.config, хотя я уже знаю, как абстрагировать это с помощью log4net).

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

Если TFS не может этого сделать, у кого-нибудь есть другие предложения?

Answer 1

Предложение Джеффа наиболее близко к тому, что мы бы порекомендовали. Рассмотрим внутренние API-интерфейсы как отдельный командный проект, который обслуживает другие проекты в качестве клиентов. Эти проекты поддерживают отставание и циклы выпуска. Вы можете иметь сборки CI, Beta и Release по своему усмотрению. Потребительские / потребительские проекты тогда используют их выбранную сборку, поскольку они могут соответствующим образом приспособиться к их собственному циклу выпуска. Поскольку ваши сборки TFS будут перемещаться в доступное место, люди тянут, а не вы выпускаете новые версии. Pull выбирает и эти сборки должны быть зарегистрированы и иметь версию в рамках проекта-потребителя. Это ничем не отличается от того, что вы сделали бы с настоящей сторонней сборкой, на самом деле вы должны рассмотреть их в том же свете.

Когда потребляющим приложениям требуется или пропускная способность для обновления до новых версий внутренних сборок, они тянут.

Answer 2

TFS не имеет понятия «общих» папок (например, как у нас с Visual SourceSafe). Рабочие пространства дают вам некоторую гибкость, но она ломается, как только вы пытаетесь сопоставить одну и ту же «общую» папку с более чем одним проектом. На ум приходит только пара вариантов, которые могут решить вашу конкретную ситуацию:

1. Разветвите проект регистрации в каждом командном проекте, который нуждается в этом. Когда вы вносите изменения в проект ведения журнала, вам нужно либо A) объединить изменения проекта ведения журнала в каждый проект, для которого он был разветвлен ("push"), либо B) попросите, чтобы каждая команда проекта, использующая изменения в журнале, выполнила слияние для получения последних изменений ("pull").

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

Могут быть и другие решения (как правило, есть), но это все, что приходит в голову от руки.

Надеюсь, это поможет.

Answer 3

В TFS 2018 :

Если ваше решение содержит проекты (.csproj), которые находятся в другом хранилище проектов TFS 2018, вы все равно можете ссылаться на эти библиотеки DLL, выполнив следующие 2 шага:

1. Ссылка включает в себя должны быть относительно того же корня. Ваши исходные сопоставления рабочей области должны имитировать ту же структуру в управлении исходным кодом. то есть. (в файле .csproj, используя ссылку на проект)

    <ProjectReference Include="..\..\..\OtherTFSProject\src\ProjectDLL\ProjectDLL.csproj">
      <Project>{e8ed9a74-a9e9-47de-ab08-0b554a950606}</Project>
      <Name>ProjectDLL</Name>
    </ProjectReference>

2. В TFS2018, когда вы создаете сборку , вы должны добавить отображение рабочего пространства в фазе " Get Sources " сборки к другой TFS хранилище проекта. Я рекомендую добавлять сопоставления в самые нижние папки, так как сборка будет компилировать все проекты в выбранном вами каталоге. В приведенном выше примере вы бы выбрали

$\OtherTFSProject\src\ProjectDLL

Я не нашел онлайн-документацию по этой проблеме. Надеюсь, это поможет!

Answer 4

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

Answer 5

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