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

[Matthew Mastracci]

Sorry for the double-followup.  Here's how we've seen that Windows is 
doing it:

C:\WINNT\assembly\GAC\System.Data>dir
  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 
build time.

This would create a directory structure like so:

$prefix/lib/mono/1.2.33.11__b3241231232222/__AssemblyInfo__.ini
$prefix/lib/mono/1.2.33.11__b3241231232222/SomeAssembly.dll

The next time, it would create:

$prefix/lib/mono/1.2.33.12__b3241231232222/__AssemblyInfo__.ini
$prefix/lib/mono/1.2.33.12__b3241231232222/SomeAssembly.dll

These files would allow someone to install SomeAssembly v1.2.33.11 and 
v1.2.33.12 in the same GAC, without interference, and without running 
gacutil.

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 
lookup.

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 
> 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.