CODEWITHSUNDEEP
version-controlnugetnuget-package
mare
mare

Reputation: 13083

How does Nuget track package versions when building in VS2010?

I've noticed for a few times now that Nuget pack will reset the package version, effectively starting from scratch and giving the package a lower version than the previous one.

I am using the asterisk * feature in VS2010 and AssemblyInfo.cs to generate versions:

// You can specify all the values or you can default the Revision and Build Numbers 
// by using the '*' as shown below:
[assembly: AssemblyVersion("1.0.0.*")]
//[assembly: AssemblyFileVersion("1.0.*")]

Now, I might have a build numbered 1.0.0.32334, then suddenly and randomly the build will become for instance 1.0.0.16272 and the same happens to the package that builds from it.

This happens completely at random (haven't figured it out yet when exactly or under what condition) but it's pretty annoying because it kills the update mechanisms for Nuget - because it finds no new versions.

Has anyone else spotted this?

Upvotes: 1

Views: 697

Answers (1)

Jim Counts
Jim Counts

Reputation: 12795

Short answer: Nuget just uses the assembly version by default, but you can override in the nuspec or on the command line..

According to MSDN the format of version numbers is this:

major.minor.build.revision

And auto-incremented build numbers behave like this:

The default build number increments daily. The default revision number is random.

When you use auto build numbering you should allow VS to auto increment the both the build and revision numbers, like the commented out example shows. Although the documentation claims randomness for revision number, in my observation it is not random. In fact, it seems to increase throughout the day and is likely to reset the next day. However, I wouldn't bank on that since it's likely an implemenation detail that could change.

By not letting VS choose the build number, you are essentially reducing it to a random number, so its not suprising that sometimes the revison number is less than the the previous revision number. Unless overriden in the nuspec or from the command line, NuGet just takes the assembly version and uses the same version for the package. So your root cause is likely the way you are choosing assembly version numbers.

If you can, just change your versioning scheme to this:

[assembly: AssemblyVersion("1.0.*")]

But if that is not acceptable, then you will have to maintain version numbers in the Nuspec or provide them on the command line when calling Nuget pack.

Upvotes: 1

Related Questions