Can I translate .net assembly versions to dates?

Question

All of my .NET assemblies uses the 1.0.* format for their version numbers. Supposedly the * gets replaced with the current date and time, translated into a number. What is the formula to translate it back into a date and time?

Answer 1

The assembly versioning is documented here: http://msdn.microsoft.com/en-us/library/51ket42z.aspx

From the quote below, I would say that what you're asking is not possible and your information is incorrect.

Assembly Version Number Each assembly has a version number as part of its identity. As such, two assemblies that differ by version number are considered by the runtime to be completely different assemblies. This version number is physically represented as a four-part string with the following format:

<major version>.<minor version>.<build> number>.<revision>

However, at the bottom of the page I linked to, there is information about custom assembly attributes and a link to setting assembly attributes. You may find something helpful there. Edit - added

I took a look at the link you posted in your answer to my comment, and the only thing I see is this:

The result of this is a build number set to the number of days since a random, designated start date and the revision based on the number of seconds since midnight.

Based on the fact that it says a "random designated start date" I would say that wha you're asking is probably possible if you can figure out what the random designated start date is, but I doubt it would be worth the effort to find out.

shameless plug for coding best pactices

You'd be better served to be using revision control and an automated build process and use the logs from those to determine an asembly's build date.

Answer 2

The version string has this format:

<major version>.<minor version>.<build number>.<revision>

and if you set the version as you've described, to 1.0.*:

The result of this is a build number set to the number of days since a random, designated start date and the revision based on the number of seconds since midnight.

The key here is "random". So, you can translate the revision to a time of day, but it sounds like you won't be able to resolve it to a date.

http://msdn.microsoft.com/en-us/library/ms998223.aspx

Answer 3

According to MSDN: "The default build number increments daily. The default revision number is random."

If you look at the source for AssemblyVersionAttribute in reflector, you will see it's not doing anything at all, just accepting the string. So the magic happens with the compiler itself, which as far as I can tell is not documented anywhere. "Incremented everyday" is pretty vague, starting from what point?

I wouldn't expect to be able to use these versions with any reliability. It is probably better to base your version off of a label in a source control system or something like that.

Answer 4

In practice, I've found that the build number is the number of days since 1 January 2000. The revision is the number of seconds since midnight on that day divided by 2.

var result = new DateTime(2000, 1, 1);
result = result.AddDays(buildNumber);
result = result.AddSeconds(revision * 2);

However, as others have already pointed out the documentation doesn't guarantee that this will always be the case.

Answer 5

Even if you could calculate the date/time from the auto-generated build number, I wouldn't recommend it. The build number wasn't meant for that purpose. It was simply meant to be an auto-generated value you can depend on to continually increase. No further logic should be assumed by a consuming application. If you want a fragment of the version number to include a date/time stamp, then you should integrate that logic into your build process / scripts / however else you may choose to do so.

Answer 6

I use a PostBuild script on my assemblies calling UpdateVersion on the AssemblyInfo.cs

We use the following format for versions |Year|Month|Day|BuildCounter|.

As the update version is open source, you can modify it to suit.

I've modified it to use the current date and a counter that is increased each build.

This way the version number always changes, and I can derive the date from the version number.

Very handy indeed.