Какова лучшая практика в подобной ситуации?Наверняка многие люди имеют дело с подобными вещами, когда широко используются github и nuget.
Вы упоминаете GitHub такЯ предложу что-то немного другое:
По моему мнению, если работа над проектом A может вызвать изменения в проекте B, ссылаться на B как на подмодуль git гораздо проще, чем работать с nuget.Подмодули Git не лишены головной боли, но для этого они и были разработаны.Некоторые из преимуществ:
1) Самое большое то, что если вы скажете: «Если мне нужно изменить B, тогда я просто внесу изменение и буду нажимать, чтобы создать новый пакет, а затем протестировать его в A»это не очень гибкая модель для работы, и она требует от разработчиков вставить непроверенный код в B. Затем этот 1-3-минутный оборот для сборки / пакета CI превращается в 3 x 1-3-минутные обороты, и это просто ужасно, когда я 'мы пробовали это в прошлом.Это огромный убийца производительности.
2) Любые другие варианты изменения файлов csproj, они могут работать, но они очень подвержены ошибкам.Разработчики не всегда замечательно рассматривают все изменения, прежде чем их зафиксировать, разработчики забудут и отметят изменение в ссылке на проект, и это вызовет сбои сборки.
3) Использование Bпоскольку подмодуль для A не мешает вам иметь автоматические сборки на B, которые производят пакеты nuget, и, возможно, другие проекты, которые с меньшей вероятностью изменят B, могут / должны ссылаться на эти
4) В какой-то моментразвитие A, если оно созревает и становится менее вероятным, чтобы вызвать изменения в B, то вы можете переключить A-> B на ссылку на пакет nuget также
Другой вариант, я помню, читал статью несколько лет назад, когда кто-тосоздал инструмент, который сгенерировал файл msbuild xproj, который заменил бы ссылки на пакеты ссылками на проекты.У них это было настроеногде файл xproj был в .gitignore, а если файл не существовал, использовалась ссылка на пакет nuget.Таким образом, разработчик запускает команду для переключения на ссылки на проекты, вносит необходимые изменения, фиксирует их, отправляет изменения, а затем обновляет ссылку на nuget.Мне это показалось довольно чистым, но я не могу найти статью, и она была немного сложнее, чем я ее озвучиваю.
Так что я все равно пошел бы по пути подмодуля git.Есть некоторые причуды с подмодулями git, но с ними стало намного легче иметь дело в последние пару лет, и кажется, что причуды легче объяснить, чем другие варианты.Воспользовавшись этим для нескольких проектов сейчас, это очень интуитивно понятно.Чтобы понять, что такое подмодуль Git в состоянии отсоединенного заголовка и как его избежать, обязательно используйте опцию -b при добавлении подмодуля и найдите хороший инструмент, который может хорошо обрабатывать подмодули.Несмотря на это, VS Code - самый интуитивно понятный интерфейс, который я нашел для работы с подмодулями.Откройте A в VS Code, затем перейдите на вкладку управления версиями, и вы увидите A и все подмодули, перечисленные вверху вместе с ветвями, которые они отслеживают.Передайте изменения в подмодуль, затем в родительский, и все готово.