Mixing packageReference and packages.config in one Solution?

4
votes

We have a large solution (mainly .NET 4.7) with a legacy ASP.NET application and many other projects. It is infeasible to move the whole solution to .NET core. Still, we no longer want to manage transitive dependencies, avoid problems with out-of-band packages, and so on.

Visual Studio 2019 has a migration assistant that can help us with moving our csproj files from packages.config to the format. Unfortunately, the assistant does not support ASP.NET projects; the main issue seems to be the web.config.

My gut feeling tells me that it would be a possibly a bad idea to move some projects to packageReference, while the ASP.NET application sticks to packages.config. But are there also fact-based reasons against the mixed usage of packageReference and packages.config in one solution?

1
asp.net.netnugetcsproj

1 Answers

6
votes

After we had run into problems after updating a transitive dependency of the RabbitMQ.Client NuGet package, we saw that we no longer want to actively manage the transitive dependencies. At least for this very project, which is unfortunately part of the really large ASP.NET solution I mentioned in my question. So we went ahead and migrated one project to packageReference, leaving all other projects with packages.config. A little bit later, we migrated all the unit and integration test projects, and a few other projects. Now we go with a "mixed solution" for two months or so. We did not experience any problems, and we went through the release lifecycle with that state.