version.Build and verions.Revision

[Kurt]

I don't get why the folowing is not working... the assembly with fileListerForm in is assigned a strong name and has a AssemblyVersion attribute of "1.0.*". It gets rebuilld and then executed. On startup I want to see the build moment (DateTime).

 

System.Version version = System.Reflection.Assembly.GetAssembly(typeof (fileListerForm)).GetName().Version;
int days = version.Build;
int seconds = version.Revision;
long startDateTime = new DateTime(2000,1,1).Ticks;
long differenceTimeSpan = new TimeSpan(days,0,0,seconds,0).Ticks;
DateTime buildTime = new DateTime(startDateTime + differenceTimeSpan);
MessageBox.Show(buildTime.ToString());

 

The build number seems to be ok, because I arrive at the correct day. But the revision number seems to be too small. When I test at 19:00 for example, the revision number (that should give the amount of seconds since midnight) makes me end up somewhere in the morning (eg. 8:55)

[Nerseus]

I don't believe the build or revision numbers have anything to do with the system's date or time. If you specify a * for a build or revision, .NET generates a random number (I believe). Could be wrong, but that's what I thought I read - the help files for .NET 1.1 don't indicate that the date/time is used for a *.

 

I would strong suggest NOT using * for any part of the build number or revision if you want to check versions. The * does NOT auto-increment the number like it did in VB6 and prior. If you want an incrementing number, you'll have to specify the values manually or use a 3rd party tool.

 

-ner

[PlausiblyDamp]

I always thought the same, but I do remember reading an article on-line somewhere that also stated they were based of date / time. However I could never get them to work as per the article.

I would agree with Nerseus and if I required versioning of my product (and I can't think of many cases wher eI wouldn't) then I would manage the build number myself.

[Kurt]

I am very sure that these generated numbers are time based though. And for the build number it certainly works, I always get the correct date of when the assembly was build. Maybe there's a problem in my source code?

However, if you would control the build number yourself, would you then do it manual, or could you think of a more automated way? I am fairly new to reflection and have no clue of how to influence the version of the build other than writing it manually in the AssemblyInfo.cs file. I am using VS 2003 EA. By the way, the time zone here is +01:00, so that wouldn't explain the time difference.

 

The actual build number generated by the compiler just happens to be an amount of days since midnight January 1, 2000, while the revision number is an amount of seconds since midnight (all UTC).

[Kurt]

ok

 

Ok, guess I just surfed enough to find an answer.

 

Build number will be equal to the number of days since January 1, 2000, local time.

Revision number will be equal to the number of seconds since midnight local time, divided by 2 (86,400 seconds in a day 5 43,200 possible rev numbers per day).

 

 

Just tested that one, and it works fine. UTC is used, as stated in previous referenced microsoft article and not the local time as stated in this quote (also from microsoft, but if you're running a site that size, I guess inconsistencies are a thing one just has got to deal with).

 

Next Line could replace the respective line in the former code list.

 

long differenceTimeSpan = new TimeSpan(days,0,0,2 * seconds,0).Ticks;

[Kurt]

I'm of course still interested in knowing how to control the version number myself in an automated way (without 3rd party controls)...

[Nerseus]

Controlling it yourself in an automated way...?

I suppose you could write an add-in for Visual Studio to bump the version in the file. If you want to build outside of Visual Studio, such as a batch file, that batch file could launch a WSH file or similar to modify the version number.

 

I prefer to do it manually by modifying the AssemblyInfo.cs file. It's not as bad as it seems, even with SourceSafe involved (have to check it out/in each time you change it).

 

In some cases it gives greater control - such as when you don't actually want to change a build/revision number on child assemblies.

 

If you use SourceSafe, an automated solution would likely require you to remember to check out the file before running/building, or would have to work with SourceSafe (ole automation) directly to automatically check the file out/in.

 

-ner