[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
place.
This would be similar to:
HKLM\Software\Microsoft\.NETFramework\AssemblyFolders
HKLM\Software\Microsoft\\VisualStudio\7.0\AssemblyFolders
HKLM\Software\Microsoft\\VisualStudio\7.1\AssemblyFolders
HKCU\Software\Microsoft\.NETFramework\AssemblyFolders
HKCU\Software\Microsoft\\VisualStudio\7.0\AssemblyFolders
HKCU\Software\Microsoft\\VisualStudio\7.1\AssemblyFolders
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:
<package>
<name>package1</name>
<description>Some package1</description>
<version>0.0.1</version>
<assemblyfolder>/opt/somepackage/lib</assemblyfolder>
</package>
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
/etc/mono/frameworks.conf)
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"
directory.
I'd love to have each framework installed in a separate flat directory,
where all the compilers and core libraries would go:
$PREFIX/mono/1.0/
$PREFIX/mono/1.1/
$PREFIX/mono/2.0/
This simple setup would solve all the issues Gert mentioned.
Jarek
----- 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
(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
> >
> >_______________________________________________
> >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