[Mono-devel-list] GAC (design) issues
tberman at sevenl.net
Mon May 3 11:00:44 EDT 2004
On Mon, 2004-03-05 at 23:36 +0900, Ian MacLean wrote:
> Todd Berman wrote:
> >On Mon, 2004-03-05 at 09:36 -0400, Joshua Tauberer wrote:
> >>Ian MacLean wrote:
> >>> From my understanding of things .net compiler references should
> >>>*always* be file paths. The assembly probing mechanism is intended for
> >>>*runtime* resolution of assemblies not compile time references.
> >>Great point.
> >Agreed, this was something that I brought up with jackson a handful of
> >days ago (believe it or not), however we decided to see what we could do
> >with just gac references.
> >The basic issue boils down to this. Having a /usr/lib/net-1.1/ assembly
> >that mcs uses to resolve is no problem, ship it in the -devel rpms, etc.
> >No issue. The issue comes with something like gtk-sharp.
> >Do you put the gtk-sharp libraries in net-1.1 and net-2.0, etc, etc?
> only if the gtk-sharp libraries need to be different between 1.1 and 2.0
> otherwise they can just reside in a gtk-sharp directory. MS only uses
> the \WINDOWS\Microsoft.NET\Framework\v1.1.4322\ directory for 'system'
> or 'framework' assemblies - ie those that ship with the base framework.
> So for mono I guess it comes down to where you draw the boundary of
> which are the 'core' assemblies. If gtk-sharp is considered to be in
> this list then it would reside with corlib.dll and friends otherwise it
> would be somewhere else.
The are completely separate and shouldnt be stored along side the
framework assemblies. That is a given.
> > If so, that becomes unmanagable really really fast.
> >So then you say, OK, 3rd party libraries install their stuff
> >into /usr/lib/LIBRARYNAME-VERSION/ and then somehow tell mcs to probe
> >that directory for runtime assemblies.
> why does mcs need to probe ? Just pass
> \r:/usr/lib/LIBRARYNAME-VERSION.dll or \r:/opt/foo/assemblyname.dll or
> whatever. gcc doesn't probe to find .h files so why should mcs.exe need
> to probe to find assembly references ?
Well, the idea would be to provide a workable robust solution, obviously
proper usage of pkg-config and PKG_CONFIG_PATH would solve this. But
again, you have no idea how many times those questions are answered all
over. Solving them would be nice ;)
> > To us, that seemed avoidable by
> >just resolving mcs references out of the gac. It also seems like a
> >better solution in the long term.
> except that now you have to know the public key token in order to
> generate a file based reference rather than just using a known base
> path. The other issue is 3rd party compilers ( nemerle, ikvm etc ) that
> will also have to implement this auto gac probing mechanism to work on mono.
That is absolutely not true :) But also unimportant.
> >However, if someone can come up with a good 3rd party solution (taking
> >into account different prefixes and all those permissions issues) I
> >would love to hear it.
> Do you mean a solution for 3rd party apps or just an alternative
> solution to the current setup ?
> If we can agree that storing a seperate copy of assemblies that reside
> in the gac for the purposes of referencing them is a reasonable thing to
> do then we'll have made a good start.
I have always felt that it was a good idea, and for the most part have
been attempting to convince myself that its not needed. Jackson and I
touched on this on irc for a bit, and Miguel has also been spoken with
briefly about it.
More information about the Mono-devel-list