[Mono-devel-list] GAC (design) issues

Gert Driesen gert.driesen at pandora.be
Fri Apr 30 05:06:21 EDT 2004


Hi Jackson,

In my opinion, the current implementation of GAC in mono has three (major?)
issues :

1. Mono system assemblies are no longer copied to a lib directory directory
where developers can explicitly reference a certain version of a system
assembly using a full path.  Can this please be put back in ?  Moreover,
wouldn't it be better to have a lib/mono/<mono version> directory (where
<mono version> is actually a major version.minor version number for major
releases, so 1.0 or 2.0 for now)  ?

You'd get the following directory structure :

lib\
    mono\
        gac\
            System\
                1.0.5000.0__b77a5c561934e089\
                    System.dll
            ....
        1.0\
            System.dll
            ....
        2.0\
bin\
    mono\
        1.0\
        2.0\

This is similar to what MS does.

Currently, removing a system assembly from the GAC will remove it completely
from your system, as its only stored in the GAC.  this would be resolved too
when these assemblies are stored in the GAC and in a Mono (version-specific)
lib directory.

2. In order to compile applications referencing system assemblies using mcs,
mcs was updated to allow unqualified assembly references to be resolved
using the  GAC (see Mono.CSharp.Driver.LoadAssemblyFromGac).  I assume this
change was only introduced to copy with the fact that system assemblies are
now only stored in the GAC, so resolving issue 1 would remove the need for
this change to mcs.

3. As part of mcs clean, assembies are removed from the gac using the
basename of the assembly, eg to remove System.Data, Version=1.0.5000.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089 from the GAC, the following
command is executed :

    gacutil /u System.Data

This could cause other versions of the System.Data assembly to be removed
from the GAC too. We should always use the fully qualified assembly names to
remove assemblies from the GAC.

Regards,

Gert




More information about the Mono-devel-list mailing list