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

[Jonathan Hogg]

On 23/10/2003 22:37, Todd Berman wrote:

> The GAC is far more than ld.so.cache, it is where the runtime looks to find
> assemblies that cant be found in (on mono) the cwd and the MONO_PATH.

Perhaps I'm missing some deeper purpose in the GAC, but that seems largely
to be what ld.so.cache is for.

In /usr/lib I have a bunch of shared libraries with different version
numbers. I compile code that links against these shared libraries. ld.so
finds the right library for me at runtime and links it in. It is helped in
this task by the ld.so.cache file.

What additional functionality does the GAC implement? I don't mean specific
details, I mean broad purpose?

I have to agree that running a special tool to (un)install a library is a
pain for package management. Running a tool post (un)installation to update
a cache isn't that much of a pain.

Despite the name, the GAC isn't really a cache. It's a repository. One can
easily create such a thing on Linux (or other unices) with a directory
structure. This should take into account the version numbers to ensure that
it's version-safe - as I understand it, the proposed model does precisely
this.

A post-install tool (a la ldconfig) can easily walk this directory, ngening
un-ngened DLLs, and extracting the strong names to put in a cache file. The
cache file would be used for fast lookup of the right DLL at runtime. If a
miss occurs on the cache file, or a false hit, then the runtime could fall
back on walking the directories itself and loading either the IL version or
the ngened one as available. That way even if the cache tool failed, you
don't fail at runtime.

Jonathan

-- 
Jonathan Hogg
Director

One Good Idea Ltd.

<http://www.onegoodidea.com/>