[Mono-devel-list] Re: Potential GAC implementation ideas.
matt at aclaro.com
Thu Oct 23 18:07:38 EDT 2003
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
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
This one isn't too bad - the package installer would place it in the
appropriately versioned directory. All files in the GAC are strongly
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".
More information about the Mono-devel-list