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

[Todd Berman]

Personally I am against that.

The internals of the GAC shouldn't be something that you as a developer, you
as a packager, or you as a user should care about. Image we go with one
format, and then 3 releases later we realize there is a way better way to do
it, and we change internal formats. That would put your package's assemblies
in the wind, and cause your application to fail.

Correct me if I am wrong, but doesn't rpm allow for commands to be run on
install and uninstall?

If so, then the packages could be inserted into the GAC with a simple
gacutil.exe /i call. This seems to be a far better way.

--Todd

> -----Original Message-----
> From: mono-devel-list-admin at lists.ximian.com [mailto:mono-devel-list-
> admin at lists.ximian.com] On Behalf Of Matthew Mastracci
> Sent: October 23, 2003 12:06 PM
> To: mono-devel-list at lists.ximian.com
> Subject: [Mono-devel-list] Re: Potential GAC implementation ideas.
> 
> 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
> 
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list