.NET assemblies version numbers

/*
Version numbers consist of two to four components: major, minor, build, and revision. The major and minor components are required; the build and revision components are optional, but the build component is required if the revision component is defined. All defined components must be integers greater than or equal to 0. The format of the version number is as follows (optional components are shown in square brackets ([ and ]):

major.minor[.build[.revision]]

The components are used by convention as follows:

-Major: Assemblies with the same name but different major versions are not interchangeable. A higher version number might indicate a major rewrite of a product where backward compatibility cannot be assumed.

-Minor: If the name and major version number on two assemblies are the same, but the minor version number is different, this indicates significant enhancement with the intention of backward compatibility. This higher minor version number might indicate a point release of a product or a fully backward-compatible new version of a product.

-Build: A difference in build number represents a recompilation of the same source. Different build numbers might be used when the processor, platform, or compiler changes.

-Revision: Assemblies with the same name, major, and minor version numbers but different revisions are intended to be fully interchangeable. A higher revision number might be used in a build that fixes a security hole in a previously released assembly.

Subsequent versions of an assembly that differ only by build or revision numbers are considered to be Hotfix updates of the prior version.

Starting with .NET Framework 2.0, the MajorRevision and MinorRevision properties enable you to identify a temporary version of your application that, for example, corrects a problem until you can release a permanent solution. Furthermore, the Windows NT operating system uses the MajorRevision property to encode the service pack number.


Assembly Version
This version number is made up of four parts, called the major, minor, build and revision numbers. Each part is a sixteen bit integer. When displayed as a full version number, the parts are usually separated with full-stop (period) characters. For example, "1.2.3.4". The assembly version number is used at run time when locating dependencies. It ensures that the correct versions of all referenced assemblies are loaded. For signed assemblies, having an incorrect assembly version can cause an application to fail to load. For this reason, it is advisable to not change this version number, except when introducing major updates or breaking changes.

File Version
This version number can be changed without affecting the loading of referenced assemblies. It is visible in a file's properties when viewed using the Windows Explorer program and is commonly structured as four integer parts, as with the assembly version. It is designed to provide a version number for an individual file, so it is common to change the number for every release of an application. Often the file version is updated automatically during the build process, perhaps incorporating information such as the build date. For example, the version number, "1.2.2012.1108" may be used for an assembly compiled on 11 August 2012.

Informational Version
This is displayed in Windows Explorer as the Product Version. The informational version can be formatted as four sixteen bit integers but often includes other text. Usually the informational version is the one that you would use when talking about your products with your users. A common approach is to assign the same information version for all of an application's assemblies.

sources: http://www.blackwasp.co.uk/Obtainingversions.aspx http://msdn.microsoft.com/en-us/library/system.version.aspx */

//The three version numbers are defined using assembly attributes, usually with the AssemblyInfo.cs file.
[assembly: AssemblyVersion("1.2.3.4")]
[assembly: AssemblyFileVersion("1.2.2012.1108")]
[assembly: AssemblyInformationalVersion("1.2 Beta")]