[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mono-devel-list
Subject:    [Mono-devel-list] GAC (design) issues
From:       "Gert Driesen" <gert.driesen () pandora ! be>
Date:       2004-04-30 9:06:21
Message-ID: 017e01c42e92$68150f10$0200a8c0 () mother
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]