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

[Matthew Mastracci]

Just a thought:

Since RedHat and other distros have been moving more towards the 
"conf.d" format of installation, why not have the GAC exist as a 
directory that RPMs can modify during install, without needing to 
"register" the DLL with GACUTIL.

It would be great if my RPM (or other package format) just needed to 
drop the DLL (and perhaps __AssemblyInfo__.ini) into the 
$prefix/lib/mono in the appropriate directory and have it "picked up". 
RPM removal would be the opposite operation - remove the added files and 
directory.  Simple!  :)

The entire process of having to register DLLs in the GAC is quite 
frustrating and adds another step to the whole process.

NGEN'ing of assemblies is something I haven't addressed here - I know 
there is no way to get around this without calling some sort of script. 
  For the most part, however, it seems like people are happy shipping 
.IL DLLs and letting the JIT take care of the rest.

Todd Berman wrote:

> Ok. Just a heads up, if the GAC or its potential implementation doesn't
> interest you, stop reading now. As well, if you can't handle somewhat
> rambling thoughts and a somewhat long email, stop right now as well. :)
> 
> This information is all stuff I've seen and looked at, I am not 100% sure of
> all of its validity, and if anyone knows that any of it is erroneous please,
> reply with your information.
> 
> First off, just a bit of background, particularly on ms.net's implementation
> of the GAC and fusion in general.
> 
> Fusion is the internal MS code name for 3 basic technologies, all tied into
> the removal of DLL hell. These 3 technologies basically comprise 1) The GAC,
> 2) Zap (the GAC for ngen'd images), 3) Downloaded Cache.
> 
> Now, ms.net has a unmanaged dll, called fusion.dll that has an api that
> deals with the GAC, documented here:
> http://support.microsoft.com/default.aspx?scid=kb;[LN];317540
> 
> There is also a thin managed wrapper (not sure how feature complete) that
> can be accessed through Reflection in mscorcfg.dll (shared assembly using
> for the .net MMCs and other configuration tools).
> 
> Now, ms.net actually stores the GAC physically on your hard drive in the
> following format:
> 
> <%windir%>/Assembly
> 	/GAC
> 		/${ASSEMBLY_NAME}
> 			/${ASSEMBLY_VERSION}__${PUBLIC_TOKEN}
> 				/${ASSEMBLY_NAME}.dll
> 				/__AssemblyInfo__.ini
> 
> This allows multiple versions of the same assembly to be stored in the gac
> without any issues.
> 
> A sample __AssemblyInfo__.ini looks like:
> 
> [AssemblyInfo]
> Signature=fa793c1dc7da9563140dc468405b7246b4363542
> MVID=a1d9480da4da0341bf4cf61f0831b455
> DisplayName=System, Version=1.0.5000.0, Culture=neutral,
> PublicKeyToken=b77a5c561934e089
> 
> All of these fields except MVID are self evident, and it seems that the MVID
> stores information that allows the GAC to potentially locate ngen'd images.
> 
> Interestingly enough, on my copy of ms.net, mscorlib is ngen'd but not in
> the GAC otherwise.
> 
> Now, onto the mono side of things. I think that the directory structure is
> the right way to do, and also the easiest way to go. Replicating it, but
> replacing <%windir%>/assembly with $prefix/lib/mono will make the most sense
> that I can see.
> 
> On windows, there is a tool, called gacutil, that is used to manipulate the
> gac on the command line. With this tool, you can install, uninstall, list,
> and generally manipulate the gac. To me, this is the first piece of the gac
> that needs to be implemented, because without it, installing assemblies into
> the gac will be more difficult than it needs to be.
> 
> With implementing the gacutil, there are several choices that I can see.
> 
> 1) make gacutil.exe a self contained .exe that can manipulate the gac on its
> own with no special external libraries. This would require the runtime to
> handle locating assemblies in the gac in their own way.
> 
> Potential Pros: Potentially easier to implement. Allows the runtime to do
> whatever it needs to do. Runtime portion will most likely be very fast.
> 
> Potential Cons: Two sets of bugs, two sets of code to maintain.
> 
> 2) an Mono specific class inside the Mono. Namespace in corlib that allows
> easy manipulation of the gac. Now, I suggested this briefly on irc, and
> Miguel disliked the idea initially because of the corlib locating itself
> issue. However, after looking a bit at ms.net, the GAC on my .net framework
> doesn't have mscorlib in it. It does have 2 native images inside the ngen
> image section, but not in the GAC part itself. Using this solution we can
> keep corlib.dll in $prefix/lib and allow the runtime to locate it that way,
> and then call into the corlib to locate the location of assemblies to bind
> to.
> 
> Potential Pros: One set of bugs, one set of code to maintain with future
> revisions, features. Its managed, and managed is good :P
> 
> Potential Cons: Might be a bit slower. Wont remove all the .dlls from
> $prefix/lib
> 
> These are just two potential implementations ideas, I would love to hear
> more, and get a good discussion going on this so we can start laying down
> some code :)
> 
> --Todd