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

[Todd Berman]

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