Project - Tiny app to automatically increment build numbers in C# NETMF projects

untitled · January 21, 2014, 3:27pm

I just posted Tiny app to automatically increment build numbers in C# NETMF projects on Codeshare. Feel free to discuss and make suggestions here.

Architect · January 21, 2014, 3:34pm

Useful

ianlee74 · January 21, 2014, 5:32pm

Visual Studio will do this for you. Edit your AssemblyInfo.cs file.

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

Note that the AssemblyFileVersionAttribute is not allowed to have asterisks if set through the UI. However, if you edit the file directly then they will work just fine.

Architect · January 21, 2014, 5:52pm

@ ianlee74 - That certainly doesn’t work in VS2012.

ianlee74 · January 21, 2014, 6:22pm

Strange. I’ve got projects where this has been working for years… I just tried on a new project and now its inserting the asterisk instead of the incremented version number. Seems something is broke in VS2012. There is one caveat that I did forget about, though. It doesn’t just increment the version number by one, it uses more of a timestamp integer that has a fairly low resolution (one day?). So, maybe not ideal if you need to increment on every single build. Great. Now I’ve got to go check in on our projects and see if they’ve been incrementing…

untitled · January 22, 2014, 2:49pm

@ ieanlee74 - I tried that * trick first, and it didn’t work for me in VS2012. After banging my head against the problem for a few hours I coded this hack. I’ve been using this code for about a year now, it’s worked great for me so far.

Another advantage of taking things into your own hands, if you’re working with a team, you can increment your build # from a server so no two developers ever use the same build number.

ianlee74 · January 23, 2014, 1:26am

@ untitled - Looks like I’ll be using this going forward. I never bothered to check that the *s were still incrementing after we upgraded to VS2012. Apparently, they aren’t… Thanks!

leforban · January 23, 2014, 3:34am

I am still updating the build number by hand, each time a customer may receive a new software version (or at least I am trying to do so, to be honnest I forgot sometimes to increase the build number). This tool could be helpfull. However does it update the build number each time we build/rebuild the project/solution? I afraid to increase build number of a thousand per week…

Dave_McLaughlin · January 23, 2014, 4:48am

As the source for the project was supplied, there is nothing stopping you making changes to increment what you need for your own app

You could for instance, only update on a daily basis or set something when you want to release the code. Selecting release build for instance, you could generate the code at that time!

leforban · January 23, 2014, 8:39am

This confirms the behaviour of the tool. But how do you update and manage the build number of your business projects? Are U used to have build number greater than a thousand? Does it makes sense to have such a big value? Are you keeping in svn repository or git system each build?

For now I update build number only when I release our application for a customer. To be honnest I don’t know where to put the threshold between release revision build major and minor. My guess was as soon as I will stop adding features (and bugs) I will increase minor… but how it works in big companies (without taking into account the marketing aspect on customers of such a raise in version number).

Reinhard_Ostermeier · January 23, 2014, 9:24am

I only use Major, Minor and Revision actively.
I update them manually when I start to make a change:
Major: Big (eventually breaking) changes, complete new implementation, …
Minor: New Features (usually no breaking changes)
Revision: Bug fixes (eventually small new features)

I set the version of all exe and dll of the solution to the identical version.

For build number I use * for assembly version and 0 for file version (no support for * here !? as mentioned already)

In TFS I have branches for every release.

I usually develop in Main branch
Every Major/Minor version change gets an Hotfix branch.
Every revision change gets an ‘RTM’ branch, which is branched from the Hotfix.


Main
+-V1.0 Hotfix
  +-RTM_V1.0.0
  +-RTM_V1.0.1
+-V1.1 Hotfix
  +-RTM_V1.1.0
+-V1.2 Hotfix
  +-RTM_V1.2.0
  +-RTM_V1.2.1
  +-RTM_V1.2.2

The Hotfix branch is always identical with the latest RTM of the same major.minor version.
This structure allows me to make bug fixes for older major.minor versions easily.

untitled · January 30, 2014, 5:43pm

Yes, my build number can run into the thousands. Currently one of my projects is at build 3102 (normally it never goes above 50, but v1.0.0 always has a ton of builds).

Once I increment any of the other numbers I reset the build to 0. …I realize not everyone uses the build number this way. In my world things work this way…

The Major changes when we break record format or device compatibility (which is rare but does happen) or when marketing decides we should increment it (which is usually the case).
The Minor changes when new features are implemented.
The Revision changes when mistakes are corrected.
The build number simply represents the number of times that Major.Minor.Revision combination was built and ensures each version number is unique.

We manually increment the Major.Minor.Revision numbers.