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

[Todd Berman]

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