[Mono-devel-list] GAC (design) issues
gert.driesen at pandora.be
Mon May 3 02:08:58 EDT 2004
Ok, so you've implemented a hack in mcs to locate assemblies in the GAC, but
what about all other (Mono) tools that allow assembly references to be
passed on the command line ? Developers using any existing .NET tool that
allows assemblies to be specified on the command line will need to specify
these as file paths anyway. The way mcs allows assembly references to be
specified is different from all other existing .NET tools. I could approve
it if it was an improvement over these existing/proven .NET tools, but it
definitely isn't ...
I really don't see what's to gain by moving away from the MS GAC
implementation. Moreover, I think its very dangerous to guess what assembly
a user want to reference.
Because that's what mcs is doing right now :
- it's guessing that you always want to reference version 1.0.5000.0
(depending on the MCS version !!) of a given assembly (both for system and
- when there's no 1.0.5000.0 version of a given assembly, then its guessing
that you want to use the first version it comes across (with the same
versions installed on both Mono and Windows, it might still cause a
different version of the assembly to be picked on Mono vs. Windows)
The current mcs hack will not work when two versions of a given assembly are
located in the GAC, and you want to explicitly reference a given version
(with a specific culture and public key token).
I agree that mcs can be updated to allow the version number to be specified
too, but in the end, what's to gain by not using file paths ??
Are we really talking about gaining a few megabytes of space (as you don't
need to have assemblies in two locations) ? Is that really worth it ? The
hack that was implemented in mcs would need to be implemented in all
existing .NET tools that take assembly references, or do you expect users to
specify the full GAC path ? (that would really improve usability) ... Do you
expect users to use file paths in all .NET tools, and only use assembly
names in one tool, named mcs ?
What I really don't understand is that you're saying that no one in the Mono
team has experience in using the MS GAC, but still you're confident enough
that you'll do a better job at implementing it than MS. I really wonder why
the Mono team chose to take a departure from MS compatibility at this point
I really get the impression that the GAC implementation was rushed in ...
Sorry if I'm rather negative about all this, but I'm just concerned ... I'm
pretty sure Novell has the resources to consult MS architects on this, to
make sure you're doing the right thing ...
----- Original Message -----
From: "Ian MacLean" <ianm at activestate.com>
To: "Todd Berman" <tberman at sevenl.net>
Cc: "Carl-Adam Brengesjö" <ca.brengesjo at telia.com>;
<mono-devel-list at lists.ximian.com>
Sent: Monday, May 03, 2004 4:59 AM
Subject: Re: [Mono-devel-list] GAC (design) issues
> Sure, but that only works because the system assemblies reside in the
> same directory as csc.exe. csc is whats found on the path not the system
> assemblies themselves.
> Todd Berman wrote:
> >On Mon, 2004-03-05 at 01:18 +0200, Carl-Adam Brengesjö wrote:
> >>On Monday 03 May 2004 00.37, Todd Berman wrote:
> >>>On Sun, 2004-02-05 at 15:39 +0200, Jaroslaw Kowalski wrote:
> >>>>No. In MS you don't have to specify a path in 2 cases:
> >>>>1. For assemblies located in the same directory as csc.exe (that is
> >>>>example \WINDOWS\Microsoft.NET\Framework\v1.1.4322)
> >>>>2. For assemblies located in the current directory
> >>>My question was about how do you specify the 1.1 framework vs the 2.0
> >>PATH anybody? Windows _do_ have it :)
> >>I belive the root folder of the framework is simply added to the PATH
> >Exactly, that was my original point in my original email.
> >Mono-devel-list mailing list
> >Mono-devel-list at lists.ximian.com
> Ian MacLean, Developer,
> ActiveState, a division of Sophos
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
More information about the Mono-devel-list