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

[Ian MacLean]

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.

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

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

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


Ian

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


-- 
Ian MacLean, Developer, 
ActiveState, a division of Sophos
http://www.ActiveState.com