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

Jonathan Hogg jonathan at onegoodidea.com
Thu Oct 23 18:28:32 EDT 2003


On 23/10/2003 22:52, Peter Williams wrote:

> But the whole point is not to put assemblies in /usr/lib due to name
> conflicts and general cleanliness, right? I think we all agree that
> hard-coding the system-specific destination path sucks:
> 
> /usr/lib/monogac/HelperAssembly/magicnumbers24134/HelperAssembly.dll
> 
> But we have to tell RPM to put the file *somewhere*. Maybe:
> 
> /usr/lib/MyMonoProgram/HelperAssembly.dll

I'm confused as to why this has to be done. The packager always knows the
version number of the DLL being installed. It's part of the strong name,
just not part of the filename. So make it part of the filename:

    /usr/lib/monogac/HelperAssembly/1.0.3.456/HelperAssembly.dll

1.0.3.456 is not a magic number, it's a quite clearly defined and well
understood number.

The above is cross-platform to any UNIX and, besides the prefix and
path-separators, Windows.

When the cache tool is run it creates:

    /usr/lib/monogac/HelperAssembly/1.0.3.456/HelperAssembly.so

and updates

    /usr/lib/monogac/cache.db

(or something similar).

How, exactly, is the process of installing a DLL into the GAC different to
installing

    /usr/lib/libfoo.so.1.3.5

and running ldconfig?

[The above can of course, also be extended to include the public key portion
of a strong name if that is necessary to differentiate DLLs (can two
identically named/numbered DLLs with differing keys be put in the GAC?).]

Jonathan

-- 
Jonathan Hogg
Director

One Good Idea Ltd.

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




More information about the Mono-devel-list mailing list