[Mono-devel-list] Re: Potential GAC implementation ideas.
matt at aclaro.com
Thu Oct 23 18:17:34 EDT 2003
Sorry for the double-followup. Here's how we've seen that Windows is
Volume in drive C has no label.
Volume Serial Number is 58CA-79E8
Directory of C:\WINNT\assembly\GAC\System.Data
05/02/2003 11:23a <DIR> .
05/02/2003 11:23a <DIR> ..
05/02/2003 11:23a <DIR> 1.0.3300.0__b77a5c561934e089
05/01/2003 03:32p <DIR> 1.0.5000.0__b77a5c561934e089
There's no reason this same layout wouldn't work under Linux. The
packager would likely run gacutil -i --gacroot=$prefix during package
This would create a directory structure like so:
The next time, it would create:
These files would allow someone to install SomeAssembly v188.8.131.52 and
v184.108.40.206 in the same GAC, without interference, and without running
If necessary (the model doesn't require this), gacutil --cache could be
run as "post-install" to pre-cache locations of GAC files for faster
Matthew Mastracci wrote:
> 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
> 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