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

[Joshua Tauberer]

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.

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