Menu
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
779
Update a package. In Solution Explorer, right-click either References or the desired project, and select Manage NuGet Packages.... (In web site projects, right-click the Bin folder.) Select the Updates tab to see packages that have available updates from the selected package sources.
Right-click the Packages folder in the project, and select Update. This will update the NuGet package to the latest version. You can double-click the Add packages and choose the specific version.
In Visual Studio, use the Help > About Microsoft Visual Studio command and look at the version displayed next to NuGet Package Manager. Alternatively, launch the Package Manager Console (Tools > NuGet Package Manager > Package Manager Console) and enter $host to see information about NuGet including the version.
Today, a project's NuGet package information is stored in a project-level packages. config folder. The assemblies are stored in a separate packages folder, usually at the solution level.
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).
147
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
