Как организовать проекты Visual Studio с открытым исходным кодом с зависимостями с открытым исходным кодом?

Question

Я начал проект MVC4 с открытым исходным кодом, который использует какой-то другой проект с открытым исходным кодом в качестве зависимости. Я разветвил другой проект и буду модифицировать его в соответствии с моими потребностями. Проблема, с которой я сталкиваюсь, заключается в том, как поддерживать эти проекты в зависимости друг от друга, но поддерживаться отдельно. Тем не менее, люди, которые вытаскивают мой проект, тоже получат проект зависимости.

1. Я могу заблокировать весь связанный код из другого проекта в моем репозитории, но таким образом я не смогу внести вклад в вилку зависимого проекта. Я просто стану частью моего репозитория. Не хочу этого делать.
2. Я могу полностью поддерживать другой проект и копировать *. DLL-файлы в свой проект. И фиксировать зависимые файлы dll в git. Это хорошо, но я теряю способность одновременно разрабатывать два проекта, а также вступать в зависимый код при отладке (ну, может быть, нет, если копировать файлы * .pdb)
3. Как и в пункте 2, я могу построить nuget пакеты из зависимого проекта и добавить их в мой основной проект - опять же, не могут реально разрабатывать оба проекта одновременно, нужно переключать контексты.
4. С некоторой магией есть файл решения, который объединяет проекты из моего репозитория и из зависимого репозитория. На каждую сборку, скопируйте файлы dll в папку/lib и скопируйте их. Таким образом, мне не нужно переключать контексты между отдельными проектами. Но недостатком является то, что другие участники git вытаскивают мой проект, они не получают зависимого проекта, и файлы решений, скорее всего, будут нарушены для них, потому что он будет ссылаться на проект, который не находится в репо.

Как организовать код в этом случае?

Answer 1

Обычно я использую nuget для всех моих зависимостей. Когда я создаю проект, я развожу его на nuget, а также на symbol source. Таким образом, вы можете беспрепятственно войти в источник зависимости.

Дополнительную информацию о источнике сигнала и nuget см. Также: Creating and Publishing a Symbol Package. Для включения отладки источника символов см. http://www.symbolsource.org/Public/Home/VisualStudio.

Необходимо также помнить, что активировать функцию Nuget package restore.

С помощью этого решения вы не можете изменить исходный код, но по крайней мере вы можете его отладить.

Answer 2

В случае, если вы не создаете циклических зависимостей после идея:

1. добавить новый проект Class Library с уникальным именем, скажем ClassLibrary1, к решению

2. в Build страница настроек проекта, конфигурация Output path к пути вывода приложения

3. в Build Events страницы, добавьте следующую строку в Post-build event command line блока:

   del "$(TargetPath)" 
   

4. повторите шаг 1 до 3, но дает другое имя, скажем, ClassLibrary2 и конфигурации Output path к исходному пути ClassLibrary1

5. набора Project Dependancies из ClassLibrary1, проверить ClassLibrary2

6. добавить все другой проект в качестве ссылки проекта в ClassLibrary2, оставьте Copy Local со значением по умолчанию true

7. сборки ClassLibrary2 один раз, и все библиотеки DLL в настоящее время находятся в исходном пути ClassLibrary1

8. добавить их к обращениям ClassLibrary1 и оставить Copy Local со значением по умолчанию true

9. комплект Project Dependancies приложения и все другие проекты, которые не являются причинами круговые зависимости, проверьте ClassLibrary1

10. добавить ссылки других проектов, с пути в DLL файлы были помещены в ClassLibrary1

11. набор Copy Local всех этих дополнительных библиотек DLL в других проектах false

Таким образом, проект ClassLibrary1 быть центральным элементом управления внешними библиотеками вашего решения. Каждый раз, когда вы Rebuild Solution (или просто создаете приложение), ClassLibrary1 копирует последние DLL-файлы, добавляя ссылки на выходную папку приложения, и удаляет DLL, сгенерированную им с именем ClassLibrary1.DLL. Приложение и зависимости во время компиляции или времени выполнения будут использовать одну и ту же версию DLL, вам не нужно выполнять дополнительное развертывание или проверять каждое развертывание.

Answer 3

Я использую нечто похожее в концепции CMake, но полностью в Visual Studio. Существует относительно неизвестная особенность файлов свойств, которые могут быть включены в решения. Это позволяет создать файл, содержащий только пути к зависимостям, включить библиотеки, которые вы можете установить, и установить относительные пути, а затем потребовать от людей установить соответствующие пути для других зависимостей, которые вы не можете/не хотите включать.

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

Для небольших зависимостей и те, которые были настроены для работы с моим проектом, я сохраняю архив или свободные файлы в репозитории и использую файл свойств для их ссылки. Другие имеют инструкции о том, где их найти и как редактировать пути.

Если вас интересует такой подход, я могу подробнее остановиться на нем. Потребовалось немного работы, чтобы понять, поскольку файлы свойств не очень хорошо документированы, но работает довольно аккуратно.