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

Jaroslaw Kowalski jaak at zd.com.pl
Sat May 1 04:02:35 EDT 2004

+1 to Ian and Gert. We all suffer from NAnt not working on Linux. Fixing
nant to deal with the current mono behaviour would be a major hack, because
you can no longer specify system assemblies references in a portable manner.

Some more issues to consider before shipping v1:

1. AssemblyFolders

Having an established system for AssemblyFolders would be great to have on
mono, too. This would make dealing with installed mono-dependent
applications/libraries much easier and would help in porting Visual
Studio.NET solutions to Mono (using for example nant's <solution> task).

The idea:

Every application package installs its public dlls (to be used for
compilation) in some place and puts the path information in a well-known

This would be similar to:



This setup is currently used for Visual Studio to populate "Add
Reference..." dialog box. VS.NET stores file references in a portable manner
by storing the name of the assemblyfolder used to find the reference in
addition to storing the actual path name. Same thing could be done in
MonoDevelop to achieve compatibility.

BTW. Note that VS.NET doesn't display GAC assemblies in "Add Reference...",
as you cannot reference a file in the GAC while compiling.

On unix the structure used to keep this package information would be:

/etc/mono/packages.d/ - for system version-neutral packages
/etc/mono/1.0/packages.d/ - for system version-specific packages
/etc/mono/2.0/packages.d/ - for system version-specific packages
~/.mono/packages.d/ - for user version-neutral packages
~/.mono/1.0/packages.d/ - for user version-specific packages
~/.mono/2.0/packages.d/ - for user version-specific packages

Each directory would hold XML description files:

    <description>Some package1</description>

A tool could be created that would manage files stored in this manner,
similar to "pkgconfig".

2. Framework mapping

I also think that it would be convenient to see a
framework-version-to-mono-version mapping defined in some public and
unmovable place. It would be reused across mono versions (like

v1.0.3750 -> 1.0
v1.1.4322 -> 1.1
v2.0.3600 -> 2.0

This way a small "starter" application could be created (simiar to what
mscoree.dll does) that would just read the expected mscorlib.dll version and
route to the appropriate mono runtime.

3. Flat "framework" structure

I would refine Gert's idea of filesystem layout. I personally see no reason
to thave "mcs.exe" in the "bin" directory while the rest goes into "lib"

I'd love to have each framework installed in a separate flat directory,
where all the compilers and core libraries would go:


This simple setup would solve all the issues Gert mentioned.


----- Original Message ----- 
From: "Ian MacLean" <ianm at ActiveState.com>
To: "Gert Driesen" <gert.driesen at pandora.be>
Cc: <mono-devel-list at lists.ximian.com>; "Jackson Harper"
<jackson at ximian.com>; "Miguel de Icaza" <miguel at novell.com>
Sent: Saturday, May 01, 2004 6:32 AM
Subject: Re: [Mono-devel-list] GAC (design) issues

> +1 . On the ms implementation the gac is considered a special system
> location and is unaccessible from the filesystem ie you can't reference
> an assembly in the gac using a filesystem path. Thats why all system
> assemblies are mirrored at \WINDOWS\Microsoft.NET\Framework\{version_no}
> as well as being stored in the gac.
> Ian
> Gert Driesen wrote:
> >Hi Jackson,
> >
> >In my opinion, the current implementation of GAC in mono has three
> >issues :
> >
> >1. Mono system assemblies are no longer copied to a lib 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
> >from your system, as its only stored in the GAC.  this would be resolved
> >when these assemblies are stored in the GAC and in a Mono
> >lib directory.
> >
> >2. In order to compile applications referencing system assemblies using
> >mcs was updated to allow unqualified assembly references to be resolved
> >using the  GAC (see Mono.CSharp.Driver.LoadAssemblyFromGac).  I assume
> >change was only introduced to copy with the fact that system assemblies
> >now only stored in the GAC, so resolving issue 1 would remove the need
> >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
> >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
> >remove assemblies from the GAC.
> >
> >Regards,
> >
> >Gert
> >
> >_______________________________________________
> >Mono-devel-list mailing list
> >Mono-devel-list at lists.ximian.com
> >http://lists.ximian.com/mailman/listinfo/mono-devel-list
> >
> >
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list

More information about the Mono-devel-list mailing list