NuGet $version$ token explained
Many questions that often come to mind when building NuGet packages are related to versioning. There's one question in particular I'd like to post here because it's one of the easier to answer. The question is: How do I use the $version$ token in the NuGet manifest (nuspec) file? Where does it get the version number from?
If you look at the NuGet docs explaining the nuspec replacement tokens, it states that the following - if it doesn't, my pull request got accepted :) - The assembly version as specified by the assembly's AssemblyVersionAttribute.
That is not entirely accurate (got a pull request accepted on the docs, so this should be fixed soonish). Consider the following AssemblyInfo.cs file contents for example.
[assembly: AssemblyVersion("184.108.40.206")] [assembly: AssemblyFileVersion("220.127.116.11")] [assembly: AssemblyInformationalVersion("18.104.22.168")]
This is where most people get confused. I won’t get into the details of which version attribute you should or should not use, as there can be good reasons to use either one of them in different scenarios. I’ll focus on how nuget is using this information to provide a version number to the $version$ replacement token in the nuspec file.
Building a NuGet package using a tokenized nuspec file that relies on assembly information can be achieved in various ways, for instance:
- nuget spec <csproj> to generate the tokenized nuspec, followed by nuget pack <csproj>
- nuget spec –a <assemblyPath> inside the csproj folder to generate a non-tokenized nuspec (so with the metadata already filled in), followed by nuget pack <nuspec>
Basically, it comes down to this:
- If the AssemblyInformationalVersion attribute is available, then that one is used.
- If the AssemblyInformationalVersion attribute is not available, then the AssemblyVersion attribute is used.
- If none of the above are specified, your assembly will have a version number of 0.0.0.0, as well as the resulting package.
- NuGet totally ignores the AssemblyFileVersion attribute.
Note that this behavior is the same when skipping the nuspec at all and building a nuget package directly from an assembly, using using nuget pack <assembly.dll>.