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

[Ian MacLean]

Todd Berman wrote:

> <>On Mon, 2004-03-05 at 10:14 +0200, Gert Driesen wrote:
>
>or just mcs /r:System.Data
>have you guys even tested this? I can say that MonoDevelop (arguably the
>largest mono project available right now) compiles, and runs *perfectly*
>with this gac setup. the build system required *no* changes, and the
>only changes required to the runtime was *changing* gac assumptions that
>#D makes about the windows GAC.
>
>  
>
 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. The 
probing algorithm is quite a complex beast designed to always find the 
most appropriate assembly on variously configured deployment machines. 
At build time you should know where on disk the referenced assemblies 
reside so that you can guarentee repeatable builds - the same way you 
tell a c compiler where to find .h files at build time but resolution of 
shared libraries depends on the target machines setup.
Using assembly full ( or partial ) names at compile time seems to me to 
be an abuse of the assembly probing mechanism. Why do all the MS 
compilers insist on file paths for references if this is not the case ?

The only reason /r:System.dll works in ms.net is because System.dll 
resides in the same directory as csc.exe. If it didn't then you would 
need to specify either a relative or full path to that assembly ( or you 
could setup the response file appropriatly ). What I'm saying is that 
specifying a full path as a reference is the *normal* case on ms.net and 
its by design - not just an incidental implementation detail - thats why 
Gert is wanting to use a full path. Note that neither  /r:System.Data 
nor  /r:System.Data, Version=...,Culture=....,PublicKeyToken=... work 
with csc.exe. Again by design as the assembly probing mechanism was not 
intended for this purpose.

The same goes for the gac. Its designed to be a central store for 
locating shared assemblies at *runtime* but not for referencing them at 
compile time. All the ms documentation around it reccommends that you do 
not rely on the fact that the current implementation uses the filesystem 
and treat it as a black box. That is the reason for having all the 
system assemblies mirrored in c:\windows. The way I look at is - the 
copies in \WINDOWS\Microsoft.NET\Framework\v1.1.4322\  are the 
equivalent of .h files ie there only purpose is to be referenced for 
metadata at compile time and the copies in the gac are the equivalent of 
shared libraries ( .dll or .so ). The fact that in .net the two 
functions are combined in the same physical file is a convenience that 
shouldn't lull you into thinking that the gac is a suitable place to 
reference assemblies.

Ian



>>>And if you *dont* know what version you want, how can you be picky about
>>>what you get back?
>>>      
>>>
>>Ofcourse you need to know what version you want ...
>>
>>    
>>
>
>Well, then do: mcs /r:System.Data, Version=whatever when (and not if)
>that gets implemented. For now its not there, but it will be.
>
>  
>
>>>>I really get the impression that the GAC implementation was rushed in
>>>>        
>>>>
>>...
>>    
>>
>>>I dont believe it is being rushed in at all, however waiting any longer
>>>would have been a bad idea as well.
>>>      
>>>
>>My point is : why implement it different from MS ?  Are you really sure that
>>the Mono implementation of the GAC is better, and easier to manage than the
>>MS implementation ?  And even if it is : what happened to compatbility ?
>>And lets not forget : for any other existing .NET tool which works with
>>assembly references developers will need to specifiy the full path to an
>>assembly (or the fully qualified assembly name) anyway ...
>>
>>    
>>
>
>Ok, here is what I don't get. We implement it the same as MS, what we
>dont do is replicate every implementation detail of their SDK. Note,
>thats the SDK not the framework itself.
>
>And no, any other existing .NET tool that operates on assembly
>references will not be affected assuming they are writing proper code.
>In fact, MCS itself is most likely going to change from using that
>LoadFromGac method to something else to be even more correct, however
>the implementation itself is being worked out.
>
>For the 7th time (slight exaggeration), will you *PLEASE* explain why
>getting the absolute path to the assembly is so important to you? You
>keep explaining that you need it, without explaining why you need it. In
>my (intentionally uninformed, as you wont explain) opinion, you are
>doing something that takes advantage of the ms.net sdk's implementation
>details (like pathing) and are irritated that you might have to refit
>that code to actually work properly. I would love to be wrong, please
>help me understand.
>
>--Todd
>
>  
>
>>Gert
>>
>>_______________________________________________
>>Mono-devel-list mailing list
>>Mono-devel-list at lists.ximian.com
>>http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>    
>>
>
>_______________________________________________
>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