[Mono-devel-list] GAC (design) issues

[Miguel de Icaza]

Hello,

> > There is only one runtime as far as I can tell. And the version of the
> > libraries that mono attempts to use should be based off the corlib
> > version included in your executable, not a config mapping.
> 
> I'm not sure if this means "perfect backward compatibility", but I may be
> wrong. If I'm right though, it means the dependency hell is likely to arise.
> Remember that the runtime itself can have issues which some applications
> will rely upon which will ultimately break them when the runtime is "fixed".

Some Unix ways of dealing with this:

	* Separate prefixes for installation of software.

	* Full virtualization of the operating system (Linux on S390 or
	  the new "Zones" support in Solaris).

Sometimes runtimes are renamed to support older versions:

	/usr/bin/perl4
	/usr/bin/perl <- Perl5

Ie, its not terribly difficult to support, and has been done extensively
in the past.

> GAC is not a filesystem and shouldn't be treaded as such. Ideally the MS
> should have encrypted the contents of "\Windows\assembly\GAC" folder or put
> it into a ZIP file in the past.

In *our* implementation it is.

> BTW. Under .NET GAC has a special semantics: assemblies from the GAC are
> "shared" among appdomains in a single process. It introduces a performance
> hit when accessing static data but helps in preserving memory since only one
> copy of each routine is JITted. Is mono going to implement this feature? Do
> you think the GAC as it's implemented will fit this idea?

We already do that (pre GAC days), see the -O=shared optimization flag,
and the LoaderOptimization enum.

This is an independent issue, that we also happen to treat differently.

Miguel.