> 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. :)

"Frans Bouma [C# MVP]" <perseus.usenetNOSPAM@xs4all.nl> wrote in message
news:xn0eicsgh5na2v001@news.microsoft.com...
> 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#)
> ------------------------------------------------------------------------