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

[Gert Driesen]

We also need to construct full paths to system assemblies to build
applications targeting the .NET Compact Framework, as in that case you use
the .NET 1.1 csc, but use system assemblies located in another directory
(but having the same fully qualified assembly name).

Gert

----- 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 11:15 AM
Subject: Re: [Mono-devel-list] GAC (design) issues


> On Mon, 2004-03-05 at 11:01 +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 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 ?
> >
>
> As you said, it doesnt work right now, but since *nothing* uses this,
> its not such a big deal to have it working.
>
> > > 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 :(
> >
>
> Its no less portable than:
>
> export PATH="C:\Some\Win32\Path\To\Required\.NET\SDK" make
>
> which is what you *need* to do *always* with the ms framework.
>
> > > 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) ...
> >
>
> As I said, make seems to handle this change just fine (as evidenced by
> MD building with *no* changes). So at this point its NAnt.
>
> So lets discuss the NAnt issue in specific, as this seems to be
> completely local to NAnt, and not something affecting other
> applications.
>
> Keep in mind that my nant experience is very limited (no offense to nant
> meant at all, just a fact). The last time i even looked at nant it
> required setting some variables in a .exe.config file with locations
> such as /usr/bin and /usr/lib to get it working. Has this changed?
>
> If not, that seems to be your root problem. First of all, (and this
> would obviously require some shell script frontend to nant), all of that
> info can be gleaned via pkg-config at runtime, so there should be no
> need for that.
>
> Now. Assuming everything is the same, it seems that before you worry
> about making portable build scripts, you need to worry about making
> portable assumptions. As assuming that the path is the only way to
> specify the framework version you want doesn't seem portable.
>
> And yet again, I still dont see why you need the path to the assembly
> absolutely. I would assume that your xml format for references is
> something like:
>
> <reference name="AssemblyName" version="0.0.0.0" pubtoken="something"
> culture="somethingelse"/>
>
> or potentially those are all optional, with an option filename
> attribute.
>
> I dont understand how there would be any problem adapting the
> information given there to generate a commandline that works for mcs,
> and csc given any subset of that data.
>
> However, on the other hand, if your reference setup basically takes the
> name, and tacks it onto the end of whatever is put in as the
> frameworkDirectory in the config file, *THAT* is the portability
> problem, not the mono GAC implementation.
>
> > Gert
> >
>
> --Todd
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>