Back to the basics: version numbers

It still amazes me how so many people don’t understand (or even care about) the version number of an assembly. A version number is composed of four parts: major number, minor number, build number and revision number. For instance, here’s a valid version number:

4.10.800.1

The first two (major and minor) define what is know as the “public version” of an assembly (notice that this number is used whenever you export an assembly – ex.: COM Interop). The third number defines the build of an assembly. Suppose, for instance, that you work for a company which produces a daily build of an assembly. In this case, this number should be incremented for each day’s main build. Finally, the last part is called the revision number. You’ll change its value whenever you need to perform an “extra build” to solve a pending issue (ex.: a bug which has been found after the daily build).

Now, that we all understand version numbers, I guess I should mention that you’ll encounter several  “types” of version numbers. An assembly is always associated with three version numbers:

  • AssemblyFileVersion: used for information purposes only. It’s the number you see when you access the properties of an assembly in Windows Explorer;
  • AssemblyInformationalVersion: again, this is used for informational purposes. It indicates the version of the product that includes this assembly.
  • AssemblyVersion: this version number is stored on the metadata and it’s used by the CLR when binding to strongly named assemblies.

And I guess this sums it up for assembly versions…

Advertisements

~ by Luis Abreu on April 12, 2010.

3 Responses to “Back to the basics: version numbers”

  1. I have a question here, is build number is auto generated or I should change it manually? if auto: what about the source control (I work with TFS), is this means it will check-out the file automatically?
    Also my scenario that I have a solution with multiple project, how can I manage their version easily?

  2. The major/minor should be controlled. You can increment the build number in your full auto builds (daily, weekly, etc).

    Setting the version number in sync can be done by sharing a cs file across all the projects in your solution (when adding the file, don”t forget to use the add as link option).

    Regarding the build, I know that there”s a AssemblyInfo task that might help you (http://code.msdn.microsoft.com/AssemblyInfoTaskvers)

  3. The major/minor should be controlled. You can increment the build number in your full auto builds (daily, weekly, etc).

    Setting the version number in sync can be done by sharing a cs file across all the projects in your solution (when adding the file, don”t forget to use the add as link option).

    Regarding the build, I know that there”s a AssemblyInfo task that might help you (http://code.msdn.microsoft.com/AssemblyInfoTaskvers)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: