Re: Assembly Versioning for Multiple Frameworks and Platforms

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Bill Henning wrote:

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

--
------------------------------------------------------------------------
Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
.

Relevant Pages

  • Re: .NET versioning
    ... >> If this isn't dll hell then it's awfully close. ... > xcopy deployment, which thus means avoid the GAC if possible. ... > 2) if required, and if you really have to, copy the files to the GAC. ... If you overwrite assemblies in the GAC ...
    (microsoft.public.dotnet.framework)
  • Re: How can I use a dll with several programs?
    ... with the GAC is the possibility of a new version of a .dll unintentionally ... Maintaining backwards compatibility of a .dll by keeping ... largely removed DLL Hell from the Windows programming radar. ... 50% based on incorrect registry entries and since .NET assemblies don't ...
    (microsoft.public.dotnet.languages.vb)
  • Re: How can I use a dll with several programs?
    ... The dll hell has everything to do with versioning of dll`s stored in one ... I don't think the DLL applies to the GAC or the Win32 Side-by-Side cache ... mechanism for Win32 assemblies. ... You should share assemblies by installing them into the global assembly ...
    (microsoft.public.dotnet.languages.vb)
  • Re: How can I use a dll with several programs?
    ... with the GAC is the possibility of a new version of a .dll unintentionally ... Maintaining backwards compatibility of a .dll by keeping its ... largely removed DLL Hell from the Windows programming radar. ... 50% based on incorrect registry entries and since .NET assemblies don't ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Assembly Versioning for Multiple Frameworks and Platforms
    ... Does anyone happent to know if the 64-bit GAC is also ... version number for each framework build. ... what tool do you use to make your 1.0 assemblies? ... We use a naming scheme in the dll for the versions. ...
    (microsoft.public.dotnet.framework)