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

[Todd Berman]

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.

--Todd