Guys, some ideas inspired by the Windows world:
In order to adress DLL HELL (the situation that occured when a program
automatically upgraded a shared component, breaking others that were
perfectly happy with the old component) MS has decided to make the
dependency binding stricter. In .NET a component that requires another is
explicitly bound to a specific version of its dependency. In fact to address
the trojan issues that were mentioned by Neil this binding can be done using
public/private keys signatures. The rational behind these decisions is that
the only thing that can be safely assumed is that components were tested
against a specific version of their dependencies and therefore they are
(more or less) garanteed to work with those versions. Other assumptions have
repeatedly proved unreliable (despite component authors promisses of
backwards compatibility). So in .NET the default behaviour is to allow for
multiple instances of a component with different dependents binding to
different versions. It is still possible to override this strict binding
behaviour but this has to be an explicit choice by the user.
I tend to think this approach is more realistic than relying on
contracts/author judgement. Note however that there is no reason not to
allow explicit overriding of these bindings by the dependents author since
he his better equiped to find compatiblity problems (this could be done
automatically through a versioning database maintained in CSPAN or
something).
In summary we could:
1) bind modules to a specific version of their dependencies;
2) allow for mutiple instances of the same modules where different
dependents bind to different versions;
3) allow for explicit overriding of these bindings either by the user or by
the dependents author;
-pp