Как предотвратить смещение версии NuGet в большом монолитном (sigh :-() приложении (несколько решений, много проектов в каждом)?

Question

Мы строим все решения для общего каталога bin. Наличие разных проектов, ссылающихся на разные версии одной и той же зависимости, вредно для нашей сборки.

Итак, мы консолидировали зависимости - отлично. Но теперь версии снова начинают дрейфовать. Мы не хотим время от времени объединять их вручную - мы хотим полностью предотвратить смещение.

Почему мы не хотим использовать Пакет? Основная причина в том, что, похоже, мы потеряем возможность переносить зависимости пакета NuGet в новые элементы PackageReference в проектах. Итак, в настоящее время у нас есть файлы package.config, но мы планируем заменить их соответствующими PackageReferences. Это означает, что мы будем использовать внутреннюю поддержку NuGet в msbuild, которая, похоже, не оставляет места для Paket.

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

РЕДАКТИРОВАТЬ 1

У нас есть внутреннее репозиторий NuGet, но мы используем его для зависимостей, которые не имеют органического представления в Nuget.org, и для обмена нашими собственными внутренними пакетами.

Один из подходов - использовать только из внутреннего хранилища NuGet. Это имеет проблемы, такие как:

1. Кто загружает туда зависимости? Разработчики? Но тогда как убедиться, что они не загружают разные версии одной и той же зависимости? Выделенные люди? Тогда они становятся узким местом.
2. Небольшая вещь, но нам нужно заблокировать коммиты в центральном NuGet.config
3. Загрузка зависимости от внутреннего репозитория NuGet не является немедленной. Вы не можете просто скачать его с NuGet.org и загрузить на внутренний, потому что это будет пропускать любые переходные зависимости. Таким образом, процесс должен быть построен вокруг него.

Это все возможно, но я не хочу идти по этому пути ... Должно быть, лучший путь.

РЕДАКТИРОВАТЬ 2

Хотя мы планируем перейти на PackageReference, это займет время. И, к сожалению, до тех пор, пока у нас есть Silverlight (по крайней мере, еще один год), целая куча проектов в выделенном решении Silverlight (80+) не будет перенесена в PackageReference, потому что при этом становится невозможно отлаживать код с VS 2015 .

Далее, предположим, что мы переносим ВСЕ проекты, а затем выводим все элементы PackageReference в единый файл целей, импортированный всеми проектами. Это возможно при использовании общего каталога bin, как мы планируем. Но при проверке в VS 2017 эта установка сообщает неверную картину, что каждый отдельный проект зависит от всего набора зависимостей NuGet. Я бы предпочел этого избежать.

Answer 1

Перейдя на PackageReference, вы можете воспользоваться MSBuild. Например, у вас может быть файл MSBuild, который содержит все ваши версии зависимостей . Это может быть файл, который вам нужен <Import ... /> во всех ваших csproj файлах, или вы можете использовать Directory.Build.props. Наконец, в каждом из ваших проектов измените номер версии в любом <PackageReference на переменную MSBuild, которая использует ранее определенное вами свойство . Большинство репозиториев Microsoft с открытым исходным кодом используют эту технику, с небольшими различиями в именах файлов и в том, импортируется ли он автоматически с Directory.Build.props или с явным <Import ... />.

Хотя вы по-прежнему можете использовать пользовательский интерфейс диспетчера пакетов в Visual Studio для проверки обновлений, вы не сможете обновлять версии пакетов с его помощью (по крайней мере, это не сохранит то, как и где определены версии) , Однако просто убедитесь, что ваш файл MSBuild, который определяет версии, находится в вашем решении, поэтому вы можете тривиально открыть файл в обозревателе решений, а затем ввести новый номер версии. Добавление новых ссылок на пакеты немного сложнее, но, как правило, этого не делается. часто, и это все еще очень просто с проектами в стиле SDK, поскольку Visual Studio позволяет редактировать csproj, пока проект еще загружен.