8

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?

Hermann.Gruber
  • 1,257
  • 1
  • 12
  • 37

1 Answers1

11

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.

Hermann.Gruber
  • 1,257
  • 1
  • 12
  • 37
  • I just added a netstandard library using PackageReference to our solution where everything else uses packages.config - and for some reason one reference isnt copied to output. Did you change top-down to work properly? Because bottom-up seems to have issues for us. – Squirrelkiller Jun 08 '20 at 08:21
  • 2
    We changed the projects bottom-up to packageReference. That is, we migrated first some projects that do not reference any other project. In each project, we consistently use either packageReference or packages.config for all referenced NuGet packages. To get your problem fixed, maybe you want to open an issue at the github project of the library you reference, or at the NuGet project itself - if you think it is a bug in nuget, or in the particular nuget package. HTH – Hermann.Gruber Jun 15 '20 at 06:36
  • 1
    @Squirrelkiller I guess when using nuget.config, the "Reference" element of your referenced package has had the child element true in the csproj File - or no such child element at all, which defaults to true. In the solution explorer, this shows as "Copy Local": true. If this is your use case, and you want to mimick the old behavior, this answer may help: https://stackoverflow.com/a/55105073/2792414 – Hermann.Gruber Jun 15 '20 at 18:32