How to set your App's Version Number to auto-increment the Build and Revision portions and Display the Version in a Label

Version Birth / Immaculate Incrementation

It seems everybody wants to call the next version of their app "vNext", or "2.0" (but not "9").

That's fine, it's your app, and you can name it and version it however you wish. To keep track of which specific version (not just the major and perhaps minor portions) a member of your team or a customer is currently using, though, you probably want something more specific - in addition to major and minor, you probably also want the build and revision numbers.

This is easy to set up and make available in a C# Visual Studio app. Here's how:

From within your project, open Properties > AssemblyInfo. You should see something like this:

[assembly: AssemblyVersion("1.0.0.0")] 

To set the major and minor versions, just directly edit those first two values. Then, replace the trailing "0.0" with a star. For example, if the version you're working on is 2.0, you could do it like so:

[assembly: AssemblyVersion("2.0.*")]

Now your build and revision values will be automatically updated. Each build of your app will be distinguishable from all others builds. However, this won't do you a heck of a lot of good if you don't provide an easy way for a user to check the version value. This is easy, too. In a form (such as an "About box") put code like this in the form's constructor:

public frmAbout()
{
    InitializeComponent();
    Version versionInfo = Assembly.GetExecutingAssembly().GetName().Version;
    // Concise way to do this suggested by james_carter:
    lblVersion.Text = "Version " + versionInfo.ToString()
}

The code above assumes the form's name is "frmAbout" and it has a label named lblVersion.

Now you will only need to update version information when you go to version 2.1, or 2.5, or 3.0, or whatever you decide to use as the next version number. You could even use "Microsoft math/logic" and skip version numbers if you want to.

When a Build is not a Build

Sometimes a kiss is just a kiss, but wackily enough, sometimes a build is not really a build at all. What I'm trying to break to you ever so gently is that the Build number does not really increment with each build; rather, it increments with each day that passes. And the starting point for this rather unusual perspective of what a build is is 1/1/200. IMO, this VersionInfo member should be named something other than "Build", this being the case.

After all, to quote the late great Abraham Lincoln, calling a tail a leg doesn't make the tail a leg; and similarly, calling an arbitrarily-arrived-at value a Build number does not make it so or such.

Nevertheless, to paraphrase Vince Lombardi, when the going gets weird, the weird get going...?!? Anyway, knowing the madness behind this method, we can compute the date of the last build and display that to the user, like so:

DateTime startDate = new DateTime(2000, 1, 1);
int diffDays = versionInfo.Build;
DateTime computedDate = startDate.AddDays(diffDays);
lblLastBuilt.Text += computedDate.ToLongDateString();

Provided you have added a label to your About box, given it a design-time text value of "Last built on " , and named it "lblLastBuilt" the code above should "just work". You will see the label sport a proclamation such as: "Last built on Thursday, December 18, 2014".

Shameless Supplication

I'm still (somewhat impatiently) waiting for my Choctypus!

Note: A Choctypus, contrary to unpopular (with me) opinion, has decidedly nothing whatsoever to do with Octopi nor with Cheetahs, rather it is (what should have been obvious, methinks), a CHOColate duckbilled plaTYPUS!