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

[Todd Berman]

Just as a small aside. It would most likely still be possible to use the
ngen'd image of our corlib, however, the implementation is pretty wasteful.
But, you could use the corlib outside the GAC to locate the ngen'd image of
corlib inside Zap (or whatever it is).

Personally I am interested in seeing as much code as possible stay managed,
but that's just me. :)

--Todd

> -----Original Message-----
> From: mono-devel-list-admin at lists.ximian.com [mailto:mono-devel-list-
> admin at lists.ximian.com] On Behalf Of Jonathan Pryor
> Sent: October 23, 2003 7:37 AM
> To: Todd Berman
> Cc: mono-devel-list at ximian.com
> Subject: Re: [Mono-devel-list] Potential GAC implementation ideas.
> 
> 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
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list