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

[Peter Williams]

Hi,

On Thu, 2003-10-23 at 08:46, Todd Berman wrote:
> 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. :)

(Warning: I don't know much about the GAC so maybe I'm totally wrong
here.)

My initial thought is that it seems to be much more sensible to have a
standalone GAC control library. Shareable, the runtime can use it, no
worries about ngen'ing corlib. If the library needed to open up PE
files, though, it would be kind of wasteful to duplicate the metadata
code in already the runtime...

Anyway, if my understanding is correct, the underlying library can just
concern itself with paths, right? Ie, we can have a simple interface
like:

	char *gnugac_get_path_to_assembly (char *asm);
	char *gnugac_get_path_to_assembly_full (
		char *asm, char *pubkeytok, char *culture);
	xid   gnugac_begin_assembly_add (
		char *asm, char *pubkeytok, char *culture, 
		char **dest_path);
	void  gnugac_done_adding_assembly (xid transaction);
	....

Then we could write a simple managed interface to it that did all the
heavy lifting (copying / moving files, pubkey calculation, etc) in
managed code. Seems to me like this would be a good balance.

Another question: how does the Mono GAC interact with the Windows GAC,
if people are using the mono runtime on Windows?

Peter

-- 
Peter Williams                          peter at newton.cx

"[Ninjas] are cool; and by cool, I mean totally sweet."
                              -- REAL Ultimate Power