Tag Archives: assembly

Version handling

Sections of your program version

Software Version is actually an interesting topic, the norm in dotNet seems to be:


with different opinions on what Build and Revision are. Microsoft sees Build as a recompilation of the same source but with different processor, platform or compiler change (see https://docs.microsoft.com/en-us/dotnet/api/system.version?view=netframework-4.8), which is a bit confusing because the average programmer would see Build as the Buildnumber of the CI/Buildserver system and Revision as a potential Hotfix for an existing version (see https://softwareengineering.stackexchange.com/questions/24987/what-exactly-is-the-build-number-in-major-minor-buildnumber-Revision). It is probably because Microsoft is a gigantic company which does very serious business on a scale that we cannot grasp, so I will keep Build and Revision as the average programmer sees it.

  • Major: main version, increases for major changes in the program, cannot assure backward compatibility
  • Minor: minor version, increases with new features, backward compatibility can be assumed
  • Build: increases for each Build in the CI / Build server
  • Revision: increases when implementing a hotfix for an older version without adding any new features

Program version in Visual Studio

The version of your program is defined in the AssemblyInfo.cs file. but you can also access it under Assembly Information from your project properties.

  • If Assembly version is not explictly specified, it takes the value of
  • If File version is not explicitly specified, it takes the value of Assembly version.
  • If Product version is not explicitly specified, it takes the value of File version.

You can set a * to let VS increase your version automatically, for example 1.0.* but be careful: the wildcard in 3rd position will be the number of days since the year 2000, and the wildcard in 4th position will be the number of seconds since midnight divided by 2 (see https://stackoverflow.com/questions/826777/how-to-have-an-auto-incrementing-version-number-visual-studio). So 1.0.* is ok if you need a quick solution since the third value will always increase but it will mean nothing.

string assemblyVersion = Assembly.GetExecutingAssembly().GetName().Version.ToString(); 
string fileVersion = FileVersionInfo.GetVersionInfo(Assembly.GetExecutingAssembly().Location).FileVersion; 
string productVersion = FileVersionInfo.GetVersionInfo(Assembly.GetExecutingAssembly().Location).ProductVersion;

Source: http://all-things-pure.blogspot.com/2009/09/assembly-version-file-version-product.html

The Version class

The Version class is the way to go if you want to work with versions in C#, compare them, store them, it is native and convenient.

using System;

namespace ConsoleApp1
    public class Program
        public static void Main()
            Version version1 = new Version(1, 2);
            Version version2 = new Version(1, 2, 3, 4);
            Version version3 = new Version("");


            Console.WriteLine($"version1 < version 2 = {version1 < version2}");
            Console.WriteLine($"version2 > version 3 = {version2 > version3}");
version1 < version 2 = True
version2 > version 3 = False

Fun fact

The funny thing is that versioning is just a convention, you could do the exact opposite of everybody else and count backwards if you said this is how it works and this would be correct. But you are not a monster so keep things simple and do not confuse your poor users.

Furthermore, if you want to shine in social events with your programmer friends, tell them that each new version number of TeX, the formatting system from Donald Knuth, approaches a bit more Pi than the precedent version (you know 3.1415…). And each new version of METAFONT, the description language used to define raster fonts, also from Donald Knuth, approaches the mathematical constant e (you know, 2.7182…). The mathematician will find this very amusing but the programmer will probably have terrible nightmares.