[Mono-devel-list] GAC (design) issues
gert.driesen at pandora.be
Mon May 3 05:01:40 EDT 2004
----- Original Message -----
From: "Todd Berman" <tberman at sevenl.net>
To: "Gert Driesen" <gert.driesen at pandora.be>
Cc: "Ian MacLean" <ianm at activestate.com>; "Carl-Adam Brengesjö"
<ca.brengesjo at telia.com>; <mono-devel-list at lists.ximian.com>
Sent: Monday, May 03, 2004 10:44 AM
Subject: Re: [Mono-devel-list] GAC (design) issues
> On Mon, 2004-03-05 at 10:14 +0200, Gert Driesen wrote:
> > ----- Original Message -----
> > From: "Todd Berman" <tberman at sevenl.net>
> > To: "Gert Driesen" <gert.driesen at pandora.be>
> > Cc: "Ian MacLean" <ianm at activestate.com>; "Carl-Adam Brengesjö"
> > <ca.brengesjo at telia.com>; <mono-devel-list at lists.ximian.com>
> > Sent: Monday, May 03, 2004 8:53 AM
> > Subject: Re: [Mono-devel-list] GAC (design) issues
> or just mcs /r:System.Data
> have you guys even tested this? I can say that MonoDevelop (arguably the
> largest mono project available right now) compiles, and runs *perfectly*
> with this gac setup. the build system required *no* changes, and the
> only changes required to the runtime was *changing* gac assumptions that
> #D makes about the windows GAC.
Have you guys tested having multiple versions of a single assembly in the
GAC, and referencing a specific version ? No, because it won't work (right
now) ... What else is there to test ?
> Well, then do: mcs /r:System.Data, Version=whatever when (and not if)
> that gets implemented. For now its not there, but it will be.
Sure, that will improve portability of make files, or other build scripts :(
> Ok, here is what I don't get. We implement it the same as MS, what we
> dont do is replicate every implementation detail of their SDK. Note,
> thats the SDK not the framework itself.
> And no, any other existing .NET tool that operates on assembly
> references will not be affected assuming they are writing proper code.
> In fact, MCS itself is most likely going to change from using that
> LoadFromGac method to something else to be even more correct, however
> the implementation itself is being worked out.
> For the 7th time (slight exaggeration), will you *PLEASE* explain why
> getting the absolute path to the assembly is so important to you? You
> keep explaining that you need it, without explaining why you need it. In
> my (intentionally uninformed, as you wont explain) opinion, you are
> doing something that takes advantage of the ms.net sdk's implementation
> details (like pathing) and are irritated that you might have to refit
> that code to actually work properly.
Todd, I'm definitely not irritated ... Sorry if I sound irritated .... Again
I just want to ensure Mono (and applications targeting Mono) stay portable,
both at runtime and at compile time ...
> I would love to be wrong, please help me understand.
Its quite simple : its all about having portable build scripts (whether its
make or NAnt, or whatever) ...
More information about the Mono-devel-list