[Mono-devel-list] GAC (design) issues
Miguel de Icaza
miguel at novell.com
Sat May 1 12:11:28 EDT 2004
> > 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/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.
More information about the Mono-devel-list