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

[2a5gjx302@sneakemail.com]

At 03:10 PM 06/05/2003 +0200, you wrote:
>On 05/05/03 Fergus Henderson wrote:
>> > Since the gc.dll in mercury should be just an helper dll, I suggest
>> > renaming it to mercury-gc.dll or something like that: I think this is a
>> > good idea regardless of the name clash issues.
>> 
>> That's easier said than done.  The Mercury build system compiles each
>> Mercury module "foo" (in source file "foo.m") to "foo.dll".  The file
>> "gc.dll" comes from the Mercury standard library module named "gc".
>> It's not possible to rename that module, because that would break
>> compatibility with existing Mercury programs that refer to the module
>> by the name "gc" in their source code.
>
>Well, I guess the mercury code either loads the module using a method
>provided by your mercury implementation or it is linked in automatically
>by the compiler. In boh cases the name of the file on disk shold not
>matter much, right? Or does the mercury code do something like:
>	some_loader_function ("gc.dll")
>If I remember correctly gc.dll was a module of the main mercury runtime
>assembly and it was loaded through a type/method reference: I can't see
>nothing in that process that requires the module to be named gc.dll, but
>maybe I'm missing something.

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.

You are never going to convince all programmers everywhere to follow this
ideal of choosing unnecessarily long filenames to ensure that names never
clash with each other, and even if programmers DID do that, there could be,
for instance, another project out there called Mercury which, say, has a
garbage collector tuned for its own uses, called, as you suggest,
mercury-gc.dll. Presto, another name clash. The fact of the matter is that
not all programmers are in contact with one another and are not even
necessarily aware that the name they are choosing might already be in use.
Also, consider that the space of reasonably short filenames is much, much
smaller than the space of digital signatures for these assemblies.
Eventually, people will have to start naming their files 'mercury-gc2.dll'
and 'mercury-gc3.dll', because there will be no sensible alternatives.

>On 05/05/03 Fergus Henderson wrote:
>> > Yes, though they solve the issue for *assemblies*, program names clashes
>> > are not addressed by strong names... So we need to educate developers to
>> > use sensible names for their programs anyway.
>> 
>> By "program names", do you mean "names of *.exe files",
>> or do you mean "names referred to in program source code"?
>
>program names as the names of the files that contain the executables
>that the user runs from a shell. There is also the separate problem of
>programs embedding the name of programs to run (especially when the
>original program is written to work on a system that requires a special
>extension for file names and has a case insensitive file system...:-).

As noted earlier, the problem of namespace clashes within code is not very
difficult to work around. The problem of program names that you refer to is
not really a problem, because users can rename binaries on their local
system if they wish to concurrently use packages with the same binary name.
Alternately, they can use alternate installation paths and type them out
absolutely, or use shell aliases. What it comes down to is that the program
name is a front-end interface issue that the user can deal with relatively
easily. What the user cannot deal with is two people both making an
assembly by the same name -- that is, unless there's some way to separate
them, for instance based on a key that identifies the assembly by producing
a digital signature of its name and version. Indeed, even the programmers
would have a hard time dealing with this problem, especially if they wanted
to use both libraries with the same name simultaneously.

In any event, for mono to remain fully compatible with .NET in the Windows
environment, both able to consume code compiled in and produce code that
executes properly in the Windows environment, it will be required to
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.

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
that open source projects are free to sign their assemblies and can still
interact with closed source projects even when they have strong names.

Jonathan