[Mono-devel-list] GAC (design) issues
ianm at ActiveState.com
Mon May 3 08:59:50 EDT 2004
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
>>>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.
>>Mono-devel-list mailing list
>>Mono-devel-list at lists.ximian.com
>Mono-devel-list mailing list
>Mono-devel-list at lists.ximian.com
Ian MacLean, Developer,
ActiveState, a division of Sophos
More information about the Mono-devel-list