Back to the basics: version numbers

Published Mon, Apr 12 2010 12:05

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…

Filed under: ,

Comments

# Pr0fess0rX said on Tuesday, April 13, 2010 4:37 PM

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?  

# luisabreu said on Wednesday, April 14, 2010 2:03 PM

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 (code.msdn.microsoft.com/AssemblyInfoTaskvers)

# luisabreu said on Wednesday, April 14, 2010 2:03 PM

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 (code.msdn.microsoft.com/AssemblyInfoTaskvers)

# LA.NET [PT] said on Saturday, June 26, 2010 3:46 PM

In a previous post about basic concepts, I’ve talked a little bit about the version number and about

Leave a Comment

(required) 
(required) 
(optional)
(required) 
If you can't read this number refresh your screen
Enter the numbers above:  

Search

This Blog

Tags

Community

Archives

Syndication

Email Notifications

News




  • View Luis Abreu's profile on LinkedIn


    Follow me at Twitter

    My books

    Silverlight 4.0: Curso Completo

    ASP.NET 4.0: Curso Completo

    Portuguese LINQ book cover

    Portuguese ASP.NET 3.5 book cover

    Portuguese ASP.NET AJAX book cover

    Portuguese ASP.NET AJAX book cover