I just came across this post by Carlos J. Quintero, a .net MVP.

He explains basically what I have been encountering in dealing with versioning of assemblies.

He even points out the bug I found with auto incrementing the AssemblyFileVersion number.

Carlos J. Quintero [.NET MVP] Jun 23, 3:34 am

Newsgroups: microsoft.public.dotnet.framework
From: “Carlos J. Quintero [.NET MVP]” <carl…@NOSPAMsogecable.com> – Find messages by this author
Date: Thu, 23 Jun 2005 10:34:05 +0200
Local: Thurs, Jun 23 2005 3:34 am
Subject: Re: AssemblyVersion numbers and recompiling code
Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse

Hi Joe,

There are 2 versions that you need to take care of:

1) The version of the file: this is the version of “classic” Win32
applications or DLLs, that is, the one shown using the Properties dialog of
Windows Explorer.

It is set with the AssemblyFileVersion attribute in AssemblyInfo.vb file:

<Assembly: AssemblyFileVersion(“1.0.2.4”)­>

Notice that this attribute is not written by default when the file is
created so you need to add it by hand.

This is the version that should be autoincremented but, alas, using “1.0.*”
does not autoincrement it in each build. I would say this is a bug.

2) The version of the assembly: this is the version of .NET assemblies,
which is different than the file version. That is, this is the version shown
in the Property dialog of the GAC in the first tab (the second tab shows the
file version). For example, in Net Framework 1.1, System.Windows.Forms has a
file version 1.1.4322.573 and an assembly version 1.0.5000.0

It is set with the AssemblyVersion attribute in AssemblyInfo.vb file:

<Assembly: AssemblyVersion(“1.0.0.0”)>

Notice that this attribute is written by default when the file is created so
you don´t need to add it by hand.

This is the version that can be autoincremented using “1.0.*” but generally
you don´t want to do this because you want to keep the same assembly version
in each build until you break the backwards compatibility. I would say that
this autoincrement feature is another bug.

So:

– Change always the AssemblyFileVersion on each build.

– Change the AssemblyVersion only if you are breaking the backwards
compatibility. Do not change it for bug fixes or other minor INTERNAL
changes which won´t break clients.

– Clients can be configured through a config file to run against an exact
dll a.b.c.d or with any a.b.* build number (provided that major and minor
digits don´t change). See the .NET Framework docs about this.

—
Best regards,

Carlos J. Quintero