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

[Ian MacLean]

from the ms support site regarding referencing assemblies stored in the gac:

> Also, note that it is not possible to directly reference an assembly 
> from the GAC in your project. If you want to use an assembly from the 
> GAC, you should drop your assemblies to a local folder, and then add a 
> reference to the assembly from this folder. 


http://support.microsoft.com/default.aspx?scid=kb;en-us;306149

and from another article regarding the same thing:

> In any event, the point here is that you will have to have two copies 
> of your shared assemblies (i.e., assemblies in the GAC) on your 
> development box, one in the GAC and one in a separate location for 
> referencing at compile time.  Microsoft does this and so should you if 
> you want to make your life easier. See 
> |C:\WINDOWS\Microsoft.NET\Framework\v1.0.3705| for their compile-time 
> assemblies

http://aspalliance.com/articleViewer.aspx?aId=76&pId=-1

Ian

> 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