[Mono-devel-list] Re: Potential GAC implementation ideas.

[Matthew Mastracci]

Todd Berman wrote:

>>The advantage to just having mono pick them up automatically (a
>>conf.d-like setup) is that there's no intervention required; once you've
>>fixed the GAC they Just Work.  But the disadvantage then is that the
>>layout and implementation of the GAC become public and basically a part
>>of the mono ABI.
> 
> 
> Again, my main issue with the conf.d type setup is two-fold:
> 
> 1) Cache for a cache?!?

Note - you wouldn't need to "cache the cache".  You could just load 
directly against the assemblies in the GAC directory.  The nice thing 
about Unix (that is seriously lacking in Win32/NTFS) is that files are 
ref-counted.  Even if the file is in use by the runtime, you could still 
remove it and have the programs that have fopen'd or mmap'd it "still 
just work".

Under Windows, opening or mmap'ing a file will guarantee that the file 
is locked (against deletes/etc) until the file handle is explicitly 
closed.  This has heavily influenced parts of Microsoft's GAC design.

 > 2) Multiple versions of the same library (part of the reason the GAC 
exists)

This one isn't too bad - the package installer would place it in the 
appropriately versioned directory.  All files in the GAC are strongly 
versioned.

Note - RPMs generally build to a "shadow filesystem" with the same 
directory layout as the target filesystem.  The files written to this 
shadow filesystem are picked up and placed in the RPM archive.  The RPM 
developer can use the gacutil.exe at packaging time to place them in the 
shadowed GAC directory - after that RPM will then do "the right thing".

Matt.