Идеального решения не существует.
Когда вы используете пакет NuGet, но вам нужно внести изменения в библиотеку во время работы над приложением, которое его использует, вам нужно внести изменения в библиотеку, опубликоватьновая версия пакета, обновите свою ссылку в своем приложении, затем надейтесь, что внесенные в библиотеку изменения сработали по мере необходимости.В частности, при работе с новой функцией это происходит очень медленно, потому что дизайн вашего программного обеспечения часто меняется несколько раз: от первого запуска до завершения, и отладка становится более сложной.Если в вашей компании нет инструментов для проверки обновлений и напоминания группам о том, что обновления доступны, то вы можете попасть в ситуацию фрагментации, когда некоторые команды по-прежнему используют очень старые версии библиотеки, и если они пытаются обновить свои приложения с перерывами и нуждаются в них.дополнительное время на адаптацию к критическим изменениям в библиотеке shaed.
С другой стороны, если вы используете ссылки на проекты, отладка и реализация новых функций становятся проще, а критические изменения обнаруживаются немедленно, при условии, что у вас достаточно автоматизировано.тесты, но для этого требуется, чтобы весь код находился в одном и том же репозитории или выглядел так, как это делается (возможно, с использованием подмодулей git, или существует соглашение, согласно которому несколько репо всегда клонируются по одному и тому же относительному пути).
И Google, и Microsoft должны были внедрить свои собственные инструменты системы управления исходным кодом, чтобы иметь дело с массивными репозиториями, которые слишком велики для работы одного компьютера разработчика, а также ускорить время компиляции как блоков разработки, так и агентов CI, потому что вы этого не делаетехотите изменить 1 строку кода в одном приложении, в результате чего каждое приложение, которое компания перестраивает и тестирует.Но если ваша компания не хочет посвятить инженеров работе над системой сборки и не вносить вклад в приложения для клиентов, это невозможно.
Итак, подмодуль или множественные репозитории с относительными соглашениями о пути звучат привлекательно, но все равнотребует перекомпиляции библиотеки при каждой сборке CI, которая использует библиотеку.Ничего страшного, но если частота смены совместно используемой библиотеки очень низкая, то сделать изменения кода библиотеки легко.Кроме того, когда кто-то еще обновляет библиотеку, как вы узнаете, что вам нужно обновить субмодуль?Инструмент NuGet, вероятно, лучше подходит для проверки обновлений и фактического обновления.
Лично я всегда использую ссылки на проекты для проектов, которые уже находятся в том же решении, и ссылки на nuget для всего остального.То, что я делал в прошлом, - это когда мне нужно либо исправить ошибку, либо добавить новую функцию в упакованную библиотеку, я клонирую обе стороны репозитория, временно добавляю проект (ы) библиотеки в решение моего приложения и изменяю ссылки на nuget нассылки на проект.Затем я развиваюсь так, как будто они все в одном репо.Наконец, мне нужно вручную отменить изменения справочных данных решения / проекта и увеличить номер справочной версии пакета перед регистрацией. Так как это руководство, оно иногда идет не так, как надо.Но это лучший баланс, который я нашел до сих пор.Вы должны решить, что лучше для вашей собственной ситуации.