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

Mon May 3 06:01:26 EDT 2004

Hi,

I would like to jump into the discussion with this simple question:
Using csc.exe it is possible to reference the core dll's (the ones at the same location as csc.exe) without specifying version numbers etc. Will this functionality be preserved using mcs.exe on Mono?

Let me elaborate: If I have one version of mcs.exe at /some/folder/ and a different version, (using other versions of the core dll'se) at /some/other/folder/ - will msc.exe use the correct core dll's?

If this is the case, then why does the build-procedure of existing projects have to be changed when moved from windows to a mono-compatible system. - Why is it necessary to find the (core) assemblies (files)?

Or - Is the discussion about non-core-assemblies in the GAC? In that case I believe it is appropriate to use the latest version of the assembly unless otherwise specified?

I hope I didn't add additional confusion to the discussion. Just trying to understand why the actual assemble-files should be accessible.

Steinar Herland

-----Original Message-----
From: mono-devel-list-admin at lists.ximian.com [mailto:mono-devel-list-admin at lists.ximian.com] On Behalf Of Todd Berman
Sent: 3. mai 2004 10:16
To: Gert Driesen
Cc: Ian MacLean; Carl-Adam Brengesjö; mono-devel-list at lists.ximian.com
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