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

[Sebastien Pouliot]

>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.

Actually the code, and tools, to sign and verify assemblies are already
present.
Actually this was far easier done in C# ;-)

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

As a (mostly) Windows user I say DON'T.

Sebastien Pouliot
Security Architect, Motus Technologies, http://www.motus.com
work: spouliot at motus.com
home: spouliot at videotron.ca
blog: http://pages.infinit.net/ctech/poupou.html


-----Original Message-----
From: mono-devel-list-admin at lists.ximian.com
[mailto:mono-devel-list-admin at lists.ximian.com]On Behalf Of Peter
Williams
Sent: 23 octobre 2003 15:42
To: mono-devel-list at ximian.com
Subject: RE: [Mono-devel-list] Potential GAC implementation ideas.


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

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list at lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list