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

[Todd Berman]

On Mon, 2004-03-05 at 11:48 +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 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 ?
> 

Not that I am aware of that currently run on mono right now. This is
moot though, as it will be fixed ASAP, and is not an issue.

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

Well, There is no tried and true guarenteed method, as linux software
installation is always a *interesting* setup ;)

However, in general if you run:

pkg-config --variable=prefix mono

you will get back a path. That path can then have /bin and /lib appended
to it to get what you guys have hardcoded.

There are times with a 'interesting' mono setup that the above
commandline will not return proper info, however this is realistically
going to work 99% of the time (RPM users) and 99.9% of the time for
people who wouldnt understand what is going on.

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

Well, you would target the different libraries with the version element,
but thats unimportant ;)

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

And this is solved by referencing the assembly on the commandline by an
absolute path name?

Well, if the issue is just which assembly you default to, a (sample)
solution would be:

if you cant find the assembly anywhere else, and are going to check the
frameworkdir and are on mono, you could look at `pkg-config
--variable=libdir mono`/mono/gac/ASSEMBLYNAME/defaultversion_* and see
if it exists, and if so, pass /r:ASSEMBLYNAME, Version=defaultversion in
the command line.

Obviously you would need some way in nant of saying you wanted the mono
thats 1.1 compat or the one thats 2.0 compat or what have you.

Just a quick potential solution, not sure how feasible it is to
implement in your framework.

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

I dont understand how adding new potential elements to your xml would
break older versions. It should be possible to support both <include>
schemas.

Let me know if any of this info helped, as having nant working on mono
is important to everyone involved I would assume.

> Gert
> 

--Todd