AssemblyVersion numbers and recompiling code

  • Thread starter Thread starter Joe
  • Start date Start date
J

Joe

Can someone please point me to an Article (Knowledge base or
otherwise), or FAQ, or white paper, that explains the relationship of
DLL AssemblyVersion numbers and needing to recompile code. Most
interesting will be those cases when the changes to the DLL are
insignificant but the DLL's version number still changes. When *must* I
recompile the code that uses a changed DLL? When can I safely ignore
compiler warnings? We've gotten into the mode where all production
code is re-compiled and re-installed for every change to a DLL. I think
this is overkill. Sometimes we change the DLL and purposely do not
increment its version number, thinking this will prevent version
conflicts. Advise please.
 
Joe said:
Can someone please point me to an Article (Knowledge base or
otherwise), or FAQ, or white paper, that explains the relationship of
DLL AssemblyVersion numbers and needing to recompile code. Most
interesting will be those cases when the changes to the DLL are
insignificant but the DLL's version number still changes. When must I
recompile the code that uses a changed DLL? When can I safely ignore
compiler warnings? We've gotten into the mode where all production
code is re-compiled and re-installed for every change to a DLL. I
think this is overkill. Sometimes we change the DLL and purposely do
not increment its version number, thinking this will prevent version
conflicts. Advise please.
Click to expand...

You use assembly signing I pressume? Then use your own version
numbers and only bump the number up when you think it is that
significant that clients have to be recompiled as well (i.e.: which
they have to, as the version number is increased). If not, e.g. no
interface change, just keep the assembly version number the same.

Instead, increase the assembly FILE version each time. The GAC
installs the assembly with the highest file version if the assembly
version is the same. This way, you can deploy a signed assembly with
teh same assembly version which is still installed in the gac as it has
a higher file version number.

FB

--
 
Thanks for your reply. I take that there is no in-depth article
discussing versioning. To answer your questions, we use assembly
signing only sporatically -- I am not aware that assembly signing
matters to this issue. We current *do* use our own version numbering
by incorporating AssemblyInfo's description field into the versioning
scheme. However, I see this as a hack, not a solution. I'm just
trying to find out exactly what the versioning rules are. Why does the
compiler occasionally complain about version numbers without telling us
the files it complains about? Thanks, though.
 
Joe said:
Thanks for your reply. I take that there is no in-depth article
discussing versioning. To answer your questions, we use assembly
signing only sporatically -- I am not aware that assembly signing
matters to this issue. We current do use our own version numbering
by incorporating AssemblyInfo's description field into the versioning
scheme. However, I see this as a hack, not a solution. I'm just
trying to find out exactly what the versioning rules are. Why does
the compiler occasionally complain about version numbers without
telling us the files it complains about? Thanks, though.
Click to expand...

If you're not signing your assemblies, assembly version numbers don't
matter to the compiler, they're ignored. If you do sign your
assemblies, it matters, if you reference version 1.0.0.0 and it can
only find 2.0.0.0, or when you start the application and the assemblies
reference 1.0.0.0 but version 1.0.1.0 is found.

FB

--
 
Thanks Frans. Let's assume that our problem only occurs with signed
DLLs. We do have some. Since all our EXEs and DLLs live in one bin,
does this mean that when a signed DLL changes from 1.0.0.0 to 1.0.0.1,
that all programs that use that DLL *must* be re-compiled? Even if the
change does not affect an interface? As I mentioned, currently we put
a date in the AssemblyInfo's Description field when such a DLL change
occurs. We call this our "augmented" version number.
 
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

MZ-Tools: Productivity add-ins for Visual Studio .NET, VB6, VB5 and VBA
You can code, design and document much faster.
Free resources for add-in developers:
http://www.mztools.com
 
Carlos. This is exactly the detailed information that we needed --
even explaining why versioning is so confusing. You deserve a raise.
Tell your boss. And if there's a FAQ somewhere, this should really be
in it. Thanks.
 
Hi Joe,

I am glad that the post helped. I haven´t found a FAQ about this, but by the
way VS 2005 exposes both version attributes more clearly, rather than hiding
the AssemblyFileVersion.

PS: I will tell my boss about a raise ;-)

--
Best regards,

Carlos J. Quintero

MZ-Tools: Productivity add-ins for Visual Studio .NET, VB6, VB5 and VBA
You can code, design and document much faster.
Free resources for add-in developers:
http://www.mztools.com
 
Back
Top