VS.net 2008 - Auto Increment Build/Version Numbers, how? | Tech Off

OrigamiCar

Hi there!

Quick question to all you experts out there on something that is quite simple I'm sure.

Is there a new way in VS.net 2008 to auto increment version numbers when you build the vb.net or C# project.

In vs.net 2005, you could view the project properties, click the 'Assembly information' button and you'd see 'Assembly version' and 'File Version' boxes - this is where you can manually place the version number. However, by putting an asterisk in either the third or forth text box, then the build or revision number would autoincrement.

All well and good, but when I try to do this in 2008, I get a message saying 'A wildcard is not allowed in this field'

Gah! I'm guessing there's some other super easy and more effient way to do it in 2008, but I've been searching Google all afternoon and can't find it.

Any ideas?
Richard.

OrigamiCar

Sorry for replying to my own post, but I found the answer.
The UI in vs.net doesn't support it, you have to edit the 'My Project>AssemblyInfo.vb' file directly.

Isshou

Even VS 2005 had restrictions for Auto-increment version numbers:

1) Can't auto-increment File Version number (at least in the UI)

2) Specific format is required:

[Major].[Minor].[Build].[Revision], Major and minor need to be set by you but once you declare Build, the third field, to be automatic the Revision, fourth field, must be blank and not zero and not *.

I don't know if VS 2008 is the same or not, I'll test it later or let someone else chime in.

Manabi
Take back the web!

Isshou wrote:
Even VS 2005 had restrictions for Auto-increment version numbers:

1) Can't auto-increment File Version number (at least in the UI)

2) Specific format is required:

[Major].[Minor].[Build].[Revision], Major and minor need to be set by you but once you declare Build, the third field, to be automatic the Revision, fourth field, must be blank and not zero and not *.

I don't know if VS 2008 is the same or not, I'll test it later or let someone else chime in.

I had this same problem just recently.

In your solution explorer, click on "Show all files", I believe it's the third one near the top of that window.

(double)click on "My Project."

Next, double-click on "AssemblyInfo.vb"

In the code editor, scroll down until you've reached the bottom.

Comment out <Assembly: AssemblyFileVersion("1.0.0.0")>

Replace
<Assembly: AssemblyVersion("1.0.0.0")>
with
<Assembly: AssemblyVersion("1.0.*")>

Click 'Save'.

Then you're done!

The next time you click Build (selection/name of your project), it'll autogenerate your Build and Revision numbers for you. The only time you would have to manually edit the version number is if you're changing the Minor or Major version numbers.

JChung2006

Auto-incrementing Major and Minor version numbers makes little sense unless they're date-driven, because the compiler has no way of knowing if your build is a major or a minor change. If you needed to support auto-incrementing Major and Minor version numbers (e.g., 2008.1.31.1), you would have to create a custom MSBuild Build Task to do this and reference the custom build task in your project.

Isshou

Isshou wrote:

I don't know if VS 2008 is the same or not, I'll test it later or let someone else chime in.

I've tried it on VS 2008 with a C# project I had, setting it to 1, 0, * for the assembly version and either nothing or 1, 0, 0, 0 for the file version worked same as it does in 2005.

MobileCoder

In reply to Manabi

#Jan 31st, 2008 @ 4:03 PM

I do not get auto-incrementing of the build number when I do this with VS2008. The Build number always appears as 3272, but the revision number increments by about 30 every build. And for what it is worth, there is no <Assembly: AssemblyFileVersion("1.0.0.0")> line in the Assembly.vb file. Any idea what I might be doing wrong?

MobileCoder

In reply to MobileCoder

#Dec 16th, 2008 @ 12:38 PM

I got an answer to my question on another thread. The build number does NOT increment with every build as one, or at least I, might have thought. But it does increment every day! Revision increments every two seconds in case you were wondering. The only thing I don't understand is how the day count got set so high, 3272 in my case, since I only started this project a year ago. But I can live with it as long as it does change, even if it is only once a day.

W3bbo
The Master of Baiters

In reply to MobileCoder

#Dec 17th, 2008 @ 12:15 PM

The date is set at some epoch, 3272 days ago was just shy of 9 years ago, the year 2000.

...the same year Microsoft started work on .NET and the CLR. Which makes sense.

I imagine they would have gone for the 1970 epoch, but that would give you a build number of around 13870, which is slightly too large.

If you want customd-defined version numbers you'll need to roll your own MSBuild scripts, and I don't suggest altering AssemblyInfo with every build since that'l wreck havok with Source Control.

Yggdrasil
Pour me a cab, 'cause I can't drink no more.

In reply to W3bbo

#Dec 17th, 2008 @ 12:25 PM

Actually, having a script change AssemblyInfo.cs (actually, we split it off to its own AssemblyVersion.cs file) is exactly what our build script does. Check out -> increment version -> check in. This is exactly what version numbers are for - so I can look at a file and know if it's from build 756 or 758, and can tell if it's before or after a patch.

silverfox

In reply to W3bbo

#Dec 17th, 2008 @ 12:25 PM

Actually, the Build number is the number of days since Dec 31, 1999. The Revision number is the number of seconds since midnight, divided by 2.

pipelinecache

Setting the assembly version attribute to 1.0.* is not a good idea if you're working with signed assemblies and other (colleagues) make use of these. The other version attribute (file version) can be modified without any problems but somehow the asterix trick does not work there.

I've written an addin for Visual Studio 2005/2008 that takes care of this. You can specify wheter to update the assembly version, the file version or both. You can even specify an external assembly info file if you're saving the attributes in a different file (which you link back to multiple projects).

The best thing about this addin (at least that's what I think) is that it doesn't bites colleagues who are also working on the project/solution. I tried so many addins for build versioning and every little one had issues; adding msbuild tasks in the project file, modifying assembly version ... and tons of other issues that don't make you very populair with the project manager. I couldn't risk another faulty plugin ... so I wrote my own.

Check it out at http://www.codeplex.com/autobuildversion/ and tell me what you think.

spivonious

I just tried this with VS2008 SP1, and if you set the assembly version to 1.0.0.* and the file version to 1.0.0 (leaving the build column blank), it will automatically fill the build field.

Lukeedw

I have tried this but whenever I use it although it updates the build number, that number will not be used until the next time I build. It is almost like it updates the AssemblyInfo.vb file too late for the build process to pick it up. How can I get around this?

lensman

In reply to Lukeedw

#Feb 3rd @ 3:21 AM

You should note that multiple build numbers exist. There are Assembly Versions, Assembly File Versions, and publish versions.

Personally I let the system auto-increment the Assembly Versions Build and revision numbers. I however control the publish versions numbers manually. This way I get unique numbers for each re-compile however my deployments are only incremented when I wish them to be incremented. This allows me to develop to my hearts content while keeping the end user numbers sane.

spivonious

In reply to lensman

#Feb 4th @ 11:44 AM

That brings up an interesting question. How do people here use the four available numbers? At my company we leave the build number at zero, increment the revision number every round of testing, the minor version when a new work order is processed, and the major number when a core piece of the app is rewritten or reworked.

SkinnedKnuckles

In reply to pipelinecache

#Jan 20th @ 11:22 PM

I am using your addin in VS2008 on XP pro SP2 with the following settings.

VS setup and deployment properties

DetectNewerInstalledVersion = false

InstallAllUsers = false

RemovePreviousVersions = true

autoBuildVersion properties

UpdateFileVersion = true

UpdateAssemblyVersion = true

The file version number and the assembly version in assemblyInfo.cs are incremented with each compile just fine. If I install my program and then make changes and build a new setup.msi everything is fine. But when I try to execute setup.msi, windows gives me the infamous "Another Version of this software is already installed." If, however, I generate a new product code identifier for the setup project before building setup.msi, it overwrites the previous installation and works just fine. The only problem is that it doesn't remove the previous entry from the "Currently Installed Programs" list in Add/Remove programs. Am I missing something or doing something wrong?

puzzled,

Jonathan

BitFlipper

I use this one:

http://www.codeproject.com/KB/macros/versioningcontrolledbuild.aspx

It works well, but you have to open it and tell it to increment the version numbers manually, but it takes just 3 clicks to do all projects in the solution. I always do that just before checking code in.