NuGet Package version not matching reference version

Question

I have been debugging an issue with my program and I find that the version of a couple of my NuGet packages do not match the version displayed in Reference Properties. For instance, looking at my installed NuGet packages I have the following:

When I select log4net in the References group (under Solution Explorer) I see this:

NuGet reports that the installed version is 2.0.5 but the Reference reports a version of 1.2.15.

Can someone explain why this is and if this is an issue? I have the same issue with Newtonsoft.Json where NuGet shows a version of 8.0.3 but References shows a version of 8.0.0

Answer 1

The trick is that you are comparing different things.

Nuget shows you available packages with their package version numbers . This is what the package owner has stated in package version field in nuget spec file . This version has no meaning or impact after nuget has done its job of fetching those external files to your project. Nor has it any direct relation to what's exactly contained within the package.

The reference properties on the other hand looks at a dll and does not care from which package it came from. The version shown is the version number embedded in DLL during compilation using the AssemblyVersionAttribute attribute in code. This is the version actually used during runtime to find and load the referenced logic.

Usually it would make sense if a package version and dll versions match, but there are no hard rules to enforce this. It would get tricky even if it did, as a package could contain many dlls and other files, each versioned differently.

Regarding this specific case, I have no information why the owners have made that difference nor whether it in accordance with their versioning logic. If this is not documented then you could send them a message and ask about its meaning.

The good thing is, a little confusion aside, if the dll does what you expect it to do and passes the QA then the version number difference in package does not matter in practice.

Edit: Note that version number difference in just the 3rd number is common for libraries utilizing semantic versioning practice where the third component bump represents a non-breaking bugfix release. Keeping the same AssemblyVersion (ex: "8.0.0" for Newtonsoft.Json) allows for in-place upgrade without recompiling all assemblies referencing the previous versions with same major-minor (8.0.0, 8.0.1, 8.0.2).