Похоже, что реальный вопрос заключается в том, «как я могу убедиться, что все проекты используют одну и ту же версию зависимости», но мне неясно, предложили ли вы использовать папку с общими пакетами для экономии места на диске.Использование общей папки не решит проблему с несколькими версиями, вы просто получите папку пакетов с несколькими версиями пакета, но, возможно, вы захотите сэкономить место на диске, поэтому я отвечу на это отдельным вопросом.Я собираюсь избегать сомнительного «хорошего решения», но, на мой взгляд, «лучшее решение», о котором вы просили, - это перенести все проекты в PackageReference и использовать решение, которое я предлагаю ниже.Также рассматривается возможность использования одного решения, но это не связано с версиями пакетов nuget.
Как я могу убедиться, что все мои проекты используют одну и ту же версию зависимости NuGet
- Код в нескольких репозиториях управления исходным кодом
Если ваш код распределен по нескольким репозиториям исходного кода, то если ваши межпроектные ссылки являются внутренними пакетами nuget, проекты, которые зависят от проектов из других репозиториевчерез пакет nuget транзитивно получит внешние зависимости nuget, поэтому просто избегайте обновления пакетов nuget в последующих проектах.Обновление будет означать обновление вашего исходного проекта, создание нового nuget с более высокой версией зависимостей, создание пакета, а затем обновление версии вашего внутреннего пакета в последующем проекте.Это много усилий, поэтому мне не нравится, когда приложения / системы распространяются по нескольким репозиториям исходного кода.Тем не менее могут существовать причины сделать это, которые перевешивают затраты, и для меня в этом и заключается суть инженерии, связанной с компромиссами.
- Код в одном репозитории.Несколько решений, пакеты NuGet через
packages.config
Если ваш код находится в одном репозитории, по крайней мере один из ваших проектов использует packages.config, а ваше приложение распределено по нескольким решениям, тогдабыть разумным количеством ручной работы, но чем меньше будет packages.config проектов, тем меньше будет работы.Вы можете использовать метод для одного приложения решения и сделать это несколько раз для каждого решения.
- Одно решение, NuGet упаковывает через
packages.config
Щелкните правой кнопкой мышивыберите «Управление пакетами NuGet для решения», а затем перейдите на вкладку «Consolodate».
- Пакеты NuGet с помощью
PackageReference
Если вы используете PackageReference, онне имеет значения, есть ли в вашем репо одно решение или несколько решений.Вы можете создать файл реквизита MSBuild с вашими версиями пакета NuGet.В качестве примера рассмотрим пример ASP.NET Core .Если вы поместите эти свойства в файл с именем Directory.Build.props в корне репо, новые версии MSBuild должны (я сам никогда не проверял) импортировать его автоматически.В противном случае вам нужно будет отредактировать все файлы вашего проекта, чтобы включить импорт в файл props.Затем вы редактируете файлы проекта и изменяете версию для использования свойства MSBuild.И снова пример из репозитория ASP.NET Core .Недостатком является то, что вы больше не можете использовать Visual Studio для обновления версий пакета, но вы все равно можете использовать его для проверки наличия новых версий и просмотра новых версий.
Если ваше приложение имеет несколько репозиториев и несколькопроекты используют PackageReference, вы можете посмотреть, как поместить файл props в подмодуль git или что-то подобное для вашей системы управления версиями.
В заключение
Я настоятельно рекомендую Миграция из packages.config в PackageReference , и затем вы можете использовать файл props MSBuild для автоматического сохранения всех проектов, использующих одну и ту же версию каждой зависимости.
Можно ли уменьшить дисковое пространствос помощью одной папки пакетов для нескольких решений
Во-первых, если бы все ваши проекты использовали PackageReference, это не было бы проблемой, поскольку NuGet не копирует пакеты PackageReference в папки решений, поэтому использование диска даже меньше, чем при использовании packages.config с папкой общих пакетов, посколькуу вас все еще будет одна копия в папке глобальных пакетов, а другая - в папке пакетов решений.
Но если вы не можете / не будете мигрировать в PackageReference, тогда да, как вы и просили ввопрос, вы можете использовать файл nuget.config на корневом уровне, чтобы установить <repositoryPath>packages</repositoryPath>, чтобы все решения использовали одну и ту же папку пакетов на корневом уровне, если папки решений не имеют своего собственного файла nuget.configэто отменяет настройку.Вы можете изменить packages на что угодно, но я не рекомендую использовать ..\anything, потому что ненавижу его, когда проекты пишут файлы вне своего корня хранилища.