Assembly Versioning for Multiple Frameworks and Platforms

[Bill Henning]

I have been searching high and low for an answer to this but can't find it.
Any help is greatly appreciated. My company develops .NET user interface
controls. We have customers who want builds of our products in .NET 2.0 and
others who want builds for native 64-bit. Additionally we have to still
support our .NET 1.x customers.

Right now we're compiling everything in .NET 1.0 which is compatible with
the newer .NET frameworks. However some 2.0 customers want native 2.0
assemblies only and the 64-bit customers want native 64-bit code only.

So my question is, how do we support all this via some sort of versioning
system? Making the various builds isn't really an issue but if they all
come out with the 3.0.100 version number for instance, and the .NET 1.0
build is in the GAC while an app starts up that has a .NET 2.0 build in its
bin folder, won't the .NET 1.0 one get loaded? And in that case, the .NET
2.0 assembly might have some enhancements (like new .NET 2.0 designer
enhancements) the .NET 1.0 build doesn't and then the app gets messed up
since it was expecting the newer code.

That's just one sort of issue. I'm sure there are others. How can we name
the files or set the version numbers so that builds for distinct .NET
frameworks and platforms can be distributed properly? What do other
component vendors do?

Thanks for any assistance you can provide as I'm currently lost in .NET
versioning hell.

Bill

 

[Frans Bouma [C# MVP]]

I have been searching high and low for an answer to this but can't
find it. Any help is greatly appreciated. My company develops .NET
user interface controls. We have customers who want builds of our
products in .NET 2.0 and others who want builds for native 64-bit.
Additionally we have to still support our .NET 1.x customers.

Right now we're compiling everything in .NET 1.0 which is compatible
with the newer .NET frameworks. However some 2.0 customers want
native 2.0 assemblies only and the 64-bit customers want native
64-bit code only.

So my question is, how do we support all this via some sort of
versioning system? Making the various builds isn't really an issue
but if they all come out with the 3.0.100 version number for
instance, and the .NET 1.0 build is in the GAC while an app starts up
that has a .NET 2.0 build in its bin folder, won't the .NET 1.0 one
get loaded? And in that case, the .NET 2.0 assembly might have some
enhancements (like new .NET 2.0 designer enhancements) the .NET 1.0
build doesn't and then the app gets messed up since it was expecting
the newer code.

That's just one sort of issue. I'm sure there are others. How can
we name the files or set the version numbers so that builds for
distinct .NET frameworks and platforms can be distributed properly?
What do other component vendors do?

Thanks for any assistance you can provide as I'm currently lost in
.NET versioning hell.

We use a naming scheme in the dll for the versions. So our runtime
library is for .NET 1.0: SD.LLBLGen.Pro.ORMSupportClasses.NET10.dll,
and for .NET 11, we build to SD.LLBLGen.Pro.ORMSupportClasses.NET11.dll
etc.

This way we can store them in the same folder on disk and the user can
easily see which version s/he targets without consulting the references
details. Also, it's easy to pick which dll you have to use.

Don't worry about the GAC though, the .NET 1.0 and .NET 2.0 gac are
separated entities, so you can add a dll with the same name to the .NET
2.0 gac if another dll with the same name is already in the .NET 1.x
gac.

I don't know about 64bit gac but I assume the same applies to that
platform.

The scheme with the framework version in the dll turned out to be
working very well for us. There's one caveat of course: if you have a
lot of assemblies, you obviously get alot more assemblies.

Another approach is to separate the different versions in different
folders. This has the disadvantage that you have to look into the dll
or check properties of the dll in windows to see for which platform it
is natively build. I personally find that a crappy solution, because I
have to use a tool to check what would otherwise obvious if it would
have been in the filename.

Frans

--

 

[Bill Henning]

Hi Frans,

Thanks for the reply. Does anyone happent to know if the 64-bit GAC is also
separate from the normal GAC? So like will a 64-bit version of an assembly
in .NET 2.0 be placed in the GAC as a separate entry from an "Any CPU"
version of an assembly in .NET 2.0?

Frans, in your scheme do you keep the same assembly version for all your
assemblies but just name the filename differently? So like...

SD.LLBLGen.Pro.ORMSupportClasses.NET10.dll is assembly version 1.0.0000
SD.LLBLGen.Pro.ORMSupportClasses.NET11.dll is also assembly version 1.0.0000
SD.LLBLGen.Pro.ORMSupportClasses.NET20.dll is also assembly version 1.0.0000

I have seen another company that does the same filename but change the minor
version number for the framework, like:

..NET 1.0 assembly: Company.Product.dll is assembly version 1.100.0000
..NET 1.1 assembly: Company.Product.dll is assembly version 1.101.0000
..NET 2.0 assembly: Company.Product.dll is assembly version 1.102.0000

I'm not sure I like that scheme because then you have a different minor
version number for each framework build.

Another question for you, what tool do you use to make your 1.0 assemblies?
We're looking at the MSBee tool but it only seems to support the 2.0 and 1.1
frameworks.

Bill