CODEWITHSUNDEEP
visual-studionuget
Brondahl
Brondahl

Reputation: 8557

What is the significance of the 'Version' column in Visual Studio Nuget Package Manager interface? (as distinct from the 'Installed' column)

enter image description here

The 'Installed' column is populated, but the 'Version' column isn't.

What does the 'Version' column mean? (As distinct from the 'Installed' column)

(I'm familiar with the concept of Semantic Versions; so I know exactly what the concept of a version number means for a NuGet package. I'm asking for exactly what does that column in that interface mean.)

Upvotes: 6

Views: 1334

Answers (2)

rboy
rboy

Reputation: 2165

This is what I've noticed (I can't find any references for it, maybe someone can add to it), but my experience has shown this:

When you're using the old Nuget package.config format for managing Nuget dependencies, it does NOT populate the Version field, just the Installed field.

When you switch over the new Nuget PackageReference format for managing nuget dependencies, then it populates the Version and the Installed fields.

If you're using a mix of the old package.config and PackageReference formats in your solution, the projects which are using package.config will only show the Installed field populated and those projects which use PackageReference will show both field populated.

Essentially it's a way for Nuget to tell you which format you're using in which project to manage nuget dependencies.

One way way to verify this, if you're using package.config for managing your Nuget packages, open Visual Studio options and change the default nuget preference to PackageReference. Now open a project which has multiple nuget packages installed, uninstall and reinstall one package and you'll notice that for that one package which is now managed using PackageReference it will show you the version field in addition to the installed field, where as the other packages still using the older package.config format, it will only show the installed field populated.

Upvotes: 3

Tianyu
Tianyu

Reputation: 1070

The Installed should be easy to explain, when you choose a specific NuGet package, the version of this NuGet package will be listed in the Installed column, and only listing for the project(s) which has/have it installed. So if one project doesn’t install this NuGet package, then it will show blank.

Normally, the Version represents the same thing(Installed). First of all, the Version column should only display/list version number of the NuGet which is installed in/for .NET Standard, .NET Core or .NET projects, and for .NET Framework project it won’t list. This Version will match the version that set in the project’s project file(.xxproj file), even if the specific version(set in .xxproj file) of the NuGet package is not installed. But normally, it lists the same version number with Installed column.

For example(in .xxproj file):

<ItemGroup>
    <PackageReference Include="LochNessBuilder" Version="3.0.0-alpha" />
</ItemGroup>

So obviously, the Version column lists the version number of the NuGet packages which you are using(want to use), and the Installed column lists the version number of the NuGet packages which you have installed(or prepared to use, as maybe there exist multiple versions of the same NuGet package which were installed).

I think this can be summarized as:

  1. If the specific version of NuGet package you have installed in the project, then the version number will be listed in Installed column, if not, it will be blank, and the Installed column is more likely to show that you have installed this version of NuGet package.

  2. The version number listed in Version column matches the Version property setting in .xxproj file, and is more likely to show that you are using this version of NuGet package.

  3. This two columns are usually show the same version number for one specific project.

  4. .NET Framework based project will not list the version number in Version column. It will only list for .NET Core, .NET Standard and .NET project. The reason should be related to the different structures of these framework based project/project template, and the different mechanism of how to install/copy/store/use NuGet packages.

  5. I believe this is not very important unless you see that they are different in two columns for one project.

Upvotes: 3

Related Questions