Packages.config and PackageReference in Visual Studio

Viewed 9928

I'm helping a colleague who cannot get a Visual Studio WPF project to build in our TFS 2015 build server. I've pulled (get latest) the latest version of his code into my VS 2019 instance. I can't get it to build on my dev box. When I try to build the solution on my dev box I get errors like thing:

The tag 'ModernDialog' does not exist in XML namespace 'http://firstfloorsoftware.com/ModernUI'. The tag 'Interaction.Triggers' does not exist in XML namespace 'http://schemas.microsoft.com/expression/2010/interactivity'.

When my colleague checks in changes into TFS, it fails with errors like this:

Unable to find version '5.2.0' of package 'MvvmLightLibs'. Unable to find version '1.0.9' of package 'ModernUI.WPF'.

I started by trying to update the NuGet packages he had in the project, but that hasn't worked well. Even restoring back to the latest version doesn't build on my machine.

My colleague's approach is to rip all NuGet packages out of the Visual Studio solution, then look around to find the DLLs, then put them into the project and reference them in the project. It does build on his system but doesn't on the TFS build server.

So, I've been looking around for probable causes. I came across this Microsoft document Migrate from packages.config to PackageReference. I'm not familiar with either packages.config or PackageReference, but I get the feeling that PackageReference is the "preferred" way of including NuGet packages.

This raises problems. Currently our TFS build server's highest version of Visual Studio is VS 2015. According to the referenced article, VS 2015 uses packages.config files. Anything newer than VS 2015 uses Packages (PackageReference I presume).

I've compared the failing WPF solution with another one I've worked on which builds fine on the build server. The solution that builds, I'll call it SolutionA, has a packages folder at the root of the solution, but it also has packages.config files in each project in the solution. The solution that fails to build, I'll call it SolutionB, has the packages folder at its root, and one packages.config file in the unit test project. (I think the unit project builds fine.)

Even though we're working with newer versions of Visual Studio, I suspect that the problem the build server is having is due to the build server having an older version of Visual Studio. We have a limited number of licenses for Visual Studio, so I can't put a newer version of Visual Studio on the build server. So, how do I get those packages.config files into each projects?

1 Answers

First, your solution actually uses packages.config nuget management format. And this format makes every project has a file called packages.config which lists all the nuget packages and their versions. That is the feature of packages.config nuget management format. So you should also make sure that you have commit that file into TFS.

Second, that migrate packages.config into PackageReference is not an easy work and it should be done with VS IDE. Mostly, you have to make a big change to every csproj file of the project. Actually, PackageReference is flexible and lightweight, it does not have the packages.config file and packages folder which stores all the nuget packages. Just embed them directly in proj file. And so far, PackageReference is the mainstream.

Your problem is that you did not do a nuget restore operation on TFS build to make the missing nuget packages under the packages folder so that build process will find those nuget packages and make them work.

You should add a nuget restore xxx\sln command line or task.

Please check one,two,three.

Related