Re: .NET versioning


"Frans Bouma [C# MVP]" <perseus.usenetNOSPAM@xxxxxxxxx> wrote in message
news:xn0eal98h44ao3000@xxxxxxxxxxxxxxxxxxxxx
> Richard Grimes wrote:
>
>> Frans Bouma [C# MVP] wrote:
>> > If that's the case, you could try to use assembly FILE versions
>> > instead. This is also the technique Microsoft uses for hotfixes and
>> > service packs on .NET: the version is the same (2.0.0.0) but the
>> > file version value in the assemblyfileversion attribute changes.
>> > You can install a file with a newer FILE version in the GAC even if
>> > it has the same assembly version.
>>
>> This will work with hotfixes, because Microsoft know what they are
>> doing, and anyway, they control the operating system. You *should
>> not* do this yourself because it is a return to Win32 DLL Hell.
>>
>> The reason is that the new version will overwrite the old version.
>> The GAC recognises only the .NET version, not the version in the
>> VERSIONINFO unmanaged resource, so gacutil just thinks you are
>> inserting the same assembly into the GAC and hence it overwrites
>> what's there. (When you use gacutil it will put the file in a
>> special folder with a name constructed line this: <.net
>> version>_<culture>_<publickeytoken> and since these will be the same
>> for both versions, the later one will over write the former.)
>
> Isn't that the intention? You have version 1.0.0.0 and you have a
> bugfix release. So you release a new version of the dll, same assembly
> version. You copy the file into the gac, it overwrites the old one and
> all your apps using the 1.0.0.0 version use now the bugfixes.
>
> I said 'bugfixes' thus not new features.

If this isn't dll hell then it's awfully close. What would you then do if it
turned out that the "bugfixed" version was buggy itself, but with different
bugs? You could not roll it back because the original version was
overwritten.

This also creates a situation where different versions of the same dll can
exist without any way to tell them apart (well, any good way). Relying on
the timedate stamp or the VERSIONINFO block to tell them apart it is not a
good way to handle it either. Typically the assembly version and the
VERSIONINFO contain the same version number, but the runtime does not
evaluate the VERSIONINFO information for binding purposes, so the app will
bind to the copy of the file that runtime evaluates first. A support person
will have a hard time distinguishing between the different versions of the
same assembly, and this really isn't a story I'd want to tell a customer
("yes I know it 'says' its the same version, but trust me, it's a different
version...")

Even if using publisher policy is ugly (I don't like it much myself) it is
still better then this.


>
>> So you have two assemblies installed into the GAC and two uninstall
>> processes, and yet there is only one physical file in the GAC. This
>> means that after the first uninstall has been run all applications
>> that remain that use this library will stop working. You can get
>> around this issue with GAC references.
>
> No install processes, you copy the files.

Are you suggesting that an install program manually copy the new "fixed"
versions directly over the existing files in the GAC? whew...

This is really going to get even more complicated when 64 bit gacs are in
used, along with other variants of the gac, along with all the distinctions
in naming conventions used for the subdirectories. There are already
multiple system gacs installed on systems. Also, how will this work on a
system with both v1.1 and v2.0 installed? Which gac will you overwrite?

I think that bypassing the GAC install/uninstall APIs is not a good way to
go...

>
> Uninstalling indeed removes the file, but that's not the point here.
> The point is that with a bugfix you otherwise have to produce policy
> files and / or recompiles.

That's exactly the point. Even an update that contains only bugfixes is
still a new assembly that may destabilize applications that use them. I've
experienced far too many updates that did more damage then they fixed to be
willing to overwrite a previous version...I may need it back again.


>
>> However, since this is just DLL Hell being applied to .NET, I would
>> recommend that this 'solution' should not be used.
>
> That's great but what's your 'solution' then? It's always nice to see
> people saying "I Don't recomment this!!" and at the same time they
> don't have an answer to the question: what to do instead?

For assemblies in the GAC use publisher policy or recompile...this does not
seem to be any worse then your proposal, and I think it is better in many
respects. An even better solution is to avoid using the GAC whevever
possible.

I prefer to avoid using the system GAC. I wrote my own version of a local
GAC that is deployed with my app and is xcopy deployable; it's mainly a
mechanism to ensure that shared assemblies get loaded correctly. It doesn't
do all the things that the global GAC does, but it does not need to. Updates
will only affect that application.

I think the natural tendency will be to make the system GAC become a dumping
ground for assemblies that really ought to be private but are public and
global. There will be many reasons for this, some good and some not so good.
IMO, over time the GAC will become the same sort of management nightmare
that the registry turned into.



>
> Because if you sign your assemblies, and you simply use buildnumbers
> for bugfixes, you have to use policy files to be sure everything keeps
> on working, OR Recompile everything else.

agreed.

>
> policy files require an installer, while with fileversions you can
> just drag/n/drop the dll into the gac and be done with it: for example
> in the situation where you leave it to the user to store the dlls in
> the GAC or keep them local to the application. So, for the users who
> want the dlls in the gac (or need to, because of some issues with
> fusion's loader, like Oracle's ODP.NET dlls can confuse the loader and
> it suddenly forgets probing paths) they can simply add them to the gac,
> and for the people who don't want to do that, they can simply avoid the
> GAC altogether. After all, Microsoft themselves state that if you can
> avoid the GAC you should.
>

Writing a simple program that invokes the GAC API is fairly trivial, and you
can install and remove assemblies from the GAC quite easily.

Versioning and compatibility is an extremely difficult problem. What .net
offers is not the end of the story, there's a lot more work that needs to be
done.




.

Relevant Pages

  • Re: GAC, Fusion.dll and Access Denied
    ... Sample managed code to check if you are admin or not: ... There is a bug in v1.0/v1.1 fusion GAC API that it *remembers* the ... > of a component which is contained in a strong-named DLL hosted in the ... > 2) Install that DLL into the GAC ...
    (microsoft.public.dotnet.framework.clr)
  • 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: Windows Service Install Project
    ... that starts Services that have references to assemblies in the GAC. ... Visual Studio Setup project? ... break my system when I go to install. ...
    (microsoft.public.dotnet.framework.setup)
  • 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)