[Mono-list] Some questions about shared assemlies, strong names...

Paolo Molaro lupus@ximian.com
Wed, 7 May 2003 13:36:10 +0200

On 05/06/03 2a5gjx302@sneakemail.com wrote:
> Lupus, the problem is not with the design of Mercury, but with mono's lack
> of intelligent name collision resolution. There is no reason whatsoever
> that strong names and a GAC should not be implemented. You seem to be
> pursuing this primarily out of anti-Microsoft sentiments.

Dude, you obviously didn't read any of my emails. If you want to raise
flame wars, do us a favour and keep the urge to yourself or at least
send a private email so I can ignore it and the people on the list won't
have to read your false statements.

Quote from my mail:
--cut cut--
Of course, that is the 1% of the usefulness of strong names. As always,
though, the people that need the feature have a chance of developing the
support for it: at this time this is not a priority for us.
--cut cut--

Where do you read that I said a GAC should not be implemented to spite
microsoft? Did the guy that sold you the 'mind reading' machine you're using
give you also a refund guarantee if it doesn't work? Oh, too bad, but if
I were you I'd check also what's inside the barrel of snake oil that
he gave you for free together with the mind reading machine:-)

> implement strong names. There is an issue I encountered that is likely a
> direct result of this: I compiled a System.Windows.Forms test application,
> and when I tried to run it on Windows, it told me that it could not locate
> a matching System.Windows.Forms.dll. When I compiled that source code with
> 'csc.exe', it had no difficulty finding it.

What is the number for the bug report you helpfully filed at
bugzilla.ximian.com? I'm almost sure that the issue is a consequence
of using strong names:-) Ironically, the solution is to ignore strong
names in some cases...

> Just as a matter of interest, why are you so against the implementation of
> strong names and the GAC? It isn't a threat to open source in any way, in

I'm so against having you decide what I need to work on right now.
So, what about if you help implement the feature if it's so important
to you, instead of writing useless mails? There are plenty of things you
can do to either implement it directly of helping with other stuff that
is currently way before strong names in the todo list.


lupus@debian.org                                     debian/rules
lupus@ximian.com                             Monkeys do it better