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

[Jonathan Pryor]

Just to continue discussion, there are two alternative methods of
implementing GAC support:

  - Implement GAC support as internal calls within the mono runtime,
    NOT mscorlib.dll.

  - Implement GAC support in a separate native library, and (a) P/Invoke
    into it (for gacutil), or (b) just use the library (from mono)

The upside to these options is that mscorlib.dll doesn't have to be
special (it can be ngened like any other assembly, as long as we go
through our GAC support code before loading mscorlib.dll).

Furthermore, using a separate native library, would likely simplify code
sharing with pnet.  (Though having a well-written spec and two separate
implementations between mono & pnet might be better...)

The downside is that we can't use C#.

If we only need to worry about directory structure & file lookup, then
it should be easy enough to write in C without worrying (too much) about
memory issues and bugs.  This would favor one of the above solutions.

If it's more complicated, we'll probably want to do it in managed code,
simplifying maintenance, which would favor one of Todd's suggestions.

Which would I prefer?  Whichever is easiest. :-)

 - Jon

On Thu, 2003-10-23 at 00:22, 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
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list