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

[Gert Driesen]

----- 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.

So there are no existing .NET applications that use assemblies of which
mulitple versions were released ?


>
> > > 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.

For linux, this hasn't changed no, as I couldn't find a way to determine
which Mono versions are installed, and in what locations ...  For Windows,
the available frameworks are automatically determined.

It would be great, if you could supply this information to us ... None of
the active NAnt contributors are linux experts (I've no problem admitting
this) ...

Note: we need to be able to obtain this information for all installed
frameworks (mono versions) ...

> 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"/>

Nope, as that would not make these references portable.  NAnt allows you to
switch the target framework on the fly, by always using the fully qualified
assembly names you wouldn't be able to target both .NET 1.0 and .NET 1.1
using the same build script ... at least not in a clean matter ...

In NAnt, you'd actually use the following xml format :

<references>
    <includes name="<path to a third party assembly>" />
    <includes name="System.dll" />
    <includes name="lib/*.dll" />
</references>

So, we allow full or partial paths to an assembly, and wildcards.  When an
assembly is not found in the base dir, we search for the assembly in the
framework assembly directory.

> 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.

Always using fully qualified assembly names is not an option, and for Mono,
we would not be able to search for an assembly in the framework assembly
directory, as there would no longer be such a dir (all system assemblies are
in the GAC), and we can't scan the GAC as that would mean we'd have to guess
too ...

And we can't just determine the fully qualified assembly name of a given
assembly file, as you could have NAnt running on NET 1.0 while targeting and
referencing a .NET 2.0 assembly. Meaning we wouldn't even be able to load
the assembly ...

>
> 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.

I agree our implementation is far from perfect (perhaps I would've done it
some other way, but we can't just break every existing build file out
there), but I don't see a good alternative if you want to maintain support
for multiple target frameworks, and maintain portability of the build files
... But we definitely are open to suggestions ...

Gert