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

Todd Berman tberman at sevenl.net
Mon May 3 10:07:57 EDT 2004

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?

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

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.


> I don't usually speak up on these issues, but is there any reason not to 
> do it both ways (actually all four ways)?
> It's obviously important (now obvious to me thanks to Ian) to be able to 
> reference an assembly by path name.  If a /r is an absolute path, look 
> for the assembly at that location.  This would be compatibile with MS. 
> (e.g. /r:/usr/lib/whatever/System.dll)
> Next, if the assembly is exactly the name of one of the core framework 
> assemblies that MS places in the same directory as csc, load the 
> appropriate version of the assembly from the GAC.  (The one that 
> corresponds to the version of the invoked mcs, or something.)  This 
> maintains compatibility with MS (and is a nice feature to boot).  (e.g. 
> /r:System.dll)
> Next, if the /r is a relative path, look for the assembly relative to 
> the current directory.  (e.g. /r:./System.dll or /r:YourAssembly.dll)
> Finally, if the /r specifies an assembly name, load it from the GAC with 
> the normal GAC rules.  (e.g. /r:System[, Version=blah])
> In the few minutes I've thought about it, it seems to me it would work 
> well and not break anything, and also not require multiple copies of 
> anything (provided absolute paths into the GAC work).  Apologies if I've 
> missed something obvious, of course.
> -- 
> - Joshua Tauberer
> http://taubz.for.net
> ** Nothing Unreal Exists **
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list

More information about the Mono-devel-list mailing list