Incrementing the "Build"

[Mike Edgewood]

I am trying to keep track of the number of times I compile my program.
I was under the impression that setting the build to an asterisk that
it would increment this automatically.
ie
AssemblyInfo.vb
<Assembly: AssemblyVersion("1.0.*")>

However, I am not seeing the result I would expect.

A call to my.application.Info.Version shows build of the running
program to be 2215. There is no freakin' way I've compiled this two
thousand times. Also, upon re-compile and rerun the number 2215 does
not change. What the hell?

Really confused. What am *I* doing wrong here?
..NET 2.0/VS 2005

 

[C.C. \(aka Me\)]

Well.. you are not alone in terms of wanting a true "build count" versioning
system. But, it is not to be..

The last 2 numbers you see are actually a timestamp and not a built count.
I am not sure if 2005 changes this or not (I doubt it). There are some
external 3rd party add-ons that can probably help though. Maybe do an
internet search for them or someone here can suggest one.

 

[C.C. \(aka Me\)]

From MSDN:

The format of the version string is: major. minor. build. revision.
When specifying a version, you have to at least specify major. If you
specify major and minor, you can specify an asterisk (*) for build. This
will cause build to be equal to the number of days since January 1, 2000
local time, and for revision to be equal to the number of seconds since
midnight local time, divided by 2.
If you specify major, minor, and build, you can specify an asterisk for
revision. This will cause revision to be equal to the number of seconds
since midnight local time, divided by 2.
Examples of valid version strings include:
1
1.1
1.1.*
1.1.1
1.1.1.*
1.1.1.1

 

[Mike Edgewood]

I've read that, but it makes no sense. It's giving me a headache. The
logic behind it, that is.

I, and I'm sure I'm not alone on this one, would assume "Build" to mean
exactly that, the number of times compiled (built). VB6?

The MS logic here is absolutely baffling to me. There must have been
drugs involved because that one is just, .. I don't know.. out
there.

And, in my opinion, revision should be a letter
ie Revision c
not the number of seconds since midnight.

Makes no sence. I can't say that enough. That is absolutely
rediculous! I think a formal letter from me, and anyone else who
objects to this, is in order.

 

[Clive Dixon]

In my last job we had a build system using NAnt. With NAnt it is quite easy
to set up a system to change the assembly version number (or file version
number, or both) however you wish with each build. With each build a new
source control label was created incrementing a number in the label string.
The very same number was used by the NAnt asminfo task to create the
AssemblyInfo.cs file used to build the assemblies with, the assembly and
file versions being set as desired.

 

[Patrice]

Don't know but in VS 2003 it was incremented only once per session (AFAIK
this is specific to VB.NET)... What if you quit VS and recompile ? Does the
number change.

Also it's likely you won't be able to do that.The automated numbers are
based on the day and the time you compiled the application. this is not a
counter as in VB6...

 

[C.C. \(aka Me\)]

They probably thought that people would rather manually set, or automate it
as part of a nighly build, the version number. Having it automate a
"compile" count really isnt that usefull - do you really care how many times
it was compiled?

Bets bet is to manually set the version numbers yourself when you are ready
to release the code. 1.0.0.0, 1.1.0.0, or whatever. If you have a patch/bug
fix release then maybe 1.1.1.0 or something?

Lastly, what looks better as a version: 1.0.0.0 or 1.0.0.3065, or
1.0.20456.12034.. I like the plain jane release numbers myself - a lot
easier to keep track of.

 

[Guest]

try this: http://www.codeproject.com/dotnet/VSBuildNumberAutomation.asp

I haven't tried this just as yet but how about creating an override for the
version number by using deriving a class from System.Reflection?

Yama