Смешивать packageReference и packages.config в одном решении?

Question

У нас есть большое решение (в основном. NET 4.7) с устаревшим приложением ASP. NET и многими другими проектами. Невозможно переместить весь раствор в ядро. NET. Тем не менее мы больше не хотим управлять транзитивными зависимостями, избегать проблем с внешними пакетами и т. Д.

В Visual Studio 2019 есть помощник по миграции, который может помочь нам с перемещением наши csproj файлы из packages.config в формат. К сожалению, помощник не поддерживает ASP. NET проекты ; Кажется, что основной проблемой является web.config .

. Мне кажется, что интуитивно понятно, что было бы плохой идеей перенести некоторые проекты в packageReference, тогда как ASP. NET приложение привязывается к packages.config. Но существуют ли также основанные на фактах причины, препятствующие смешанному использованию packageReference и packages.config в одном решении?

Answer 1

После того как мы столкнулись с проблемами после обновления транзитивной зависимости пакета RabbitMQ.Client NuGet , мы увидели, что больше не хотим активно управлять транзитивными зависимостями. По крайней мере, для этого самого проекта, который, к сожалению, является частью действительно большого ASP. NET решения, которое я упомянул в своем вопросе. Итак, мы продолжили и перенесли один проект в packageReference, оставив все остальные проекты с package.config. Чуть позже мы перенесли все проекты модульных и интеграционных тестов, а также несколько других проектов. Теперь мы go со «смешанным раствором» в течение двух месяцев или около того. У нас не было никаких проблем, и мы прошли жизненный цикл релиза с этим состоянием.