Совместное использование файлов csproj между решениями

Question

Я давно в этом разбираюсь и до сих пор не нашел удовлетворительных решений. У нас есть несколько общих библиотек (.csprojs), которые также зависят друг от друга, а также от сторонних библиотек. Я хочу, чтобы эти общие проекты упоминались в нескольких файлах.sln.

В прошлом мы пытались сделать эту работу с NuGet. Мы сделали все наши пакеты общих компонентов и имели местный канал. Однако, когда мы хотели обновить наши общие компоненты, это часто приводило к ошибкам в процессе обновления и было ненадежным. Это вызывает у нас больше головных болей, чем стоит, и, честно говоря, мы не хотим добавлять общий код в наши разделяемые библиотеки.

Итак, теперь я считаю, что лучше иметь ссылку на общий проект в каждом решении, это достаточно просто, но теперь есть еще одна проблема:

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

/App1
  /Development  (Folder that just contians Main branch)
     /Main
  /Features   (Folder that contains all Features)
     /F1
/App2
  /Development
     /Main
  /Features
     /F1
     /F2
/Shared
   /Development
     /Main

Однако, если мы вносим изменения в общий доступ в какой-либо из функций - и он указывает на код в /Shared/Development/Main, то он просто обновляется для всех моих функций, и мы не храним записи общих изменений.

Как правильно решить эти проблемы? Есть ли лучший способ обмена компонентами между решениями?

Answer 1

Ответьте, что мы пошли для наших проблем:

1. Возьмите все общие файлы.csproj и поместите их в свой собственный файл Main (в отдельный общий файл.sln).
2. Затем создайте модульные тесты для каждой библиотеки.
3. Укажите все другие решения на использование этих файлов.csproj в качестве ссылок на проекты. Это решения, которые находятся в другой основной или функциональной ветвях, но они всегда будут указывать на общую главную.
4. Наконец, настройте определение сборки для сборки / тестирования при регистрации и ночных сборках.

На шаге 4 вы гарантируете, что если кто-то что-то изменит в ваших общих проектах, он будет быстро обнаружен модульными тестами.

Мы все еще можем использовать NuGet в качестве оболочки для вещей, чтобы распространять их среди третьих сторон - но для внутренних изменений этот поток, кажется, работает лучше всего для быстрой разработки / тестирования.