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

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

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

Как вы упорядочиваете свой код в этом случае?

Ответ 1

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

Для получения дополнительной информации о источнике символа и nuget см. также: Создание и публикация пакета Symbol. Чтобы включить отладку источника символов, см. http://www.symbolsource.org/Public/Home/VisualStudio.

Вы также должны помнить, чтобы включить Восстановление пакета Nuget.

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

Ответ 2

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

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

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

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

Ответ 3

Если вы не создаете круговые зависимости, выполните следующую идею:

добавить новый проект Class Library с уникальным именем, например ClassLibrary1, в решение
на странице Build его параметров проекта, config Output path в путь вывода приложения
на странице Build Events добавьте следующую строку в блок Post-build event command line:
```
del "$(TargetPath)"
```
повторите шаги с 1 по 3, но введите другое имя, скажем ClassLibrary2 и config Output path, в исходный путь ClassLibrary1
установите Project Dependancies из ClassLibrary1, проверьте ClassLibrary2
добавить все остальные проекты в качестве ссылки на проект ClassLibrary2, оставить Copy Local со значением по умолчанию true
build ClassLibrary2 один раз, и все DLL теперь находятся в исходном пути ClassLibrary1
добавьте их в ссылки ClassLibrary1 и оставьте Copy Local со значением по умолчанию true
установить Project Dependancies приложения и всех других проектов, которые не вызывают круговых зависимостей, проверьте ClassLibrary1
добавить ссылки других проектов, с пути, по которому DLL были помещены в ClassLibrary1
установите Copy Local всех этих добавленных библиотек DLL в других проектах на false

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

Ответ 4

Я нашел это полезным. Спасибо за написание и хранение.