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 Version.MajorRevision and Version.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 Version.MajorRevision property to encode the service pack number.

Assigning Version Information to Assemblies

Ordinarily, the Version class is not used to assign a version number to an assembly. Instead, the System.Reflection.AssemblyVersionAttribute class is used to define an assembly's version, as illustrated by the example in this topic.

Retrieving Version Information

Version objects are most frequently used to store version information about some system or application component (such as the operating system), the common language runtime, the current application's executable, or a particular assembly. The following examples illustrate some of the most common scenarios:

• Retrieving the operating system version. The following example uses the OperatingSystem.Version property to retrieve the version number of the operating system.

  code reference: System.Version.Class#1

• Retrieving the version of the common language runtime. The following example uses the Environment.Version property to retrieve version information about the common language runtime.

  code reference: System.Version.Class#2

• Retrieving the current application's assembly version. The following example uses the System.Reflection.Assembly.GetEntryAssembly method to obtain a reference to an System.Reflection.Assembly object that represents the application executable and then retrieves its assembly version number.

  code reference: System.Version.Class#5

• Retrieving the current assembly's assembly version. The following example uses the System.Reflection.Assembly.GetExecutingAssembly method to obtain a reference to an System.Reflection.Assembly object that represents the current assembly and then retrieves its version information.

  code reference: System.Version.Class#4

• Retrieving the version of a specific assembly. The following example uses the System.Reflection.Assembly.ReflectionOnlyLoadFrom(string) method to obtain a reference to an System.Reflection.Assembly object that has a particular file name, and then retrieves its version information. Note that several other methods also exist to instantiate an System.Reflection.Assembly object by file name or by strong name.

  code reference: System.Version.Class#3

• Retrieving the Publish Version of a ClickOnce application. The following example uses the System.Deployment.Application.ApplicationDeployment.CurrentVersion property to display an application's Publish Version. Note that its successful execution requires the example's application identity to be set. This is handled automatically by the Visual Studio Publish Wizard.

  code reference: System.Version.Class#7

Comparing Version Objects

You can use the Version.CompareTo(Version) method to determine whether one Version object is earlier than, the same as, or later than a second Version object. The following example indicates that Version 2.1 is later than Version 2.0.

code reference: System.Version.Class.Comparing#1

For two versions to be equal, the major, minor, build, and revision numbers of the first Version object must be identical to those of the second Version object. If the build or revision number of a Version object is undefined, that Version object is considered to be earlier than a Version object whose build or revision number is equal to zero. The following example illustrates this by comparing three Version objects that have undefined version components.

code reference: System.Version.Class.Comparing#2

All public static members of this type are safe for multithreaded operations. No instance members are guaranteed to be thread safe.

Namespace: System
Assembly: mscorlib (in mscorlib.dll)
Assembly Versions: 1.0.5000.0, 2.0.0.0, 4.0.0.0