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

[Jonathan Hogg]

On 23/10/2003 23:33, Todd Berman wrote:

> Alright, this applies to you, and to Michal (who already got an email about
> this)

I don't believe either of us are children, and certainly don't need to be
spoken to as such.

> Please, please please please please, read the initial email that started
> this thread.

I did. I have read every email in this thread. I have sent two replies. One
to a post from you saying that "The GAC is far more than ld.so.cache", which
I disputed, and one from Peter Williams  suggesting that version numbers and
public key tokens are "magic numbers", which I also disputed.

If you feel I have missed the point, then please do point out where I am
wrong.

> It details exactly the same things you both are talking about, and it
> emulates ms' method exactly.

Yes. I didn't pretend I was suggesting anything new. To quote from your
opening post:

>> Now, onto the mono side of things. I think that the directory structure is
>> the right way to do, and also the easiest way to go. Replicating it, but
>> replacing <%windir%>/assembly with $prefix/lib/mono will make the most sense
>> that I can see.
>> 
>> On windows, there is a tool, called gacutil, that is used to manipulate the
>> gac on the command line. With this tool, you can install, uninstall, list,
>> and generally manipulate the gac. To me, this is the first piece of the gac
>> that needs to be implemented, because without it, installing assemblies into
>> the gac will be more difficult than it needs to be.

It is the second part I disagree with. I don't believe that installing
assemblies directly into the cache is difficult. I believe requiring a
command-line tool to install assemblies is difficult.

[Aside: I would have said that the first piece of the GAC to be implemented
should be the necessary runtime changes to load DLLs from it, gacutil would
seem to be the last thing that needs to exist.]

Don't get me wrong, I'm not against having a tool to do it. I'm just against
it being the only supported method.

> Now, the more recent and long part of this thread is about how a packager
> can get his assembly to the gac.
> 
> I will reiterate. As a packager, feel free to directly insert this assembly
> into the gac via copying with RPM, HOWEVER, don't expect this method to
> always work.
> 
> This is akin to using private member functions via reflection.

This is what I object to. It *must* be expected to work. UNIX is not
Windows. We always had versioned shared libraries and we always had various
sensible package managers for installing and uninstalling them.

Requiring a special tool to install a library is too brittle. If you insist
that simply copying the library into place cannot be relied upon, then you
*are* requiring the use of the tool. One does not "feel free" to use
"private member functions via reflection".

The GAC should be the least complicated it can be and it's layout should be
well documented and stable. As I, and you, have pointed out: this isn't
rocket science.

Jonathan

-- 
Jonathan Hogg
Director

One Good Idea Ltd.

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