Hi Larry,

my division uses Source Safe and we like it ok (well, it comes for free with MSDN...) but as the division grows (we now have developers in three countries across two continents) we realize that working remotely with SS is not efficient (slow slow), and we are investigating other products.

As for binary compatibility, we found out that the problem is not SS per se, but mostly the VB IDE and the virtue of the developer. If you check out a file within the IDE, the application automatically gets the latest. But if you use the IDE disconnected from SS (happens working remotely) if you check out and get the latest under SS, the IDE does not realize that a file in the project has been changed, and happily continues with the old version (to be 100% sure I always exit VB before working on SS).

I agree that binary compatibility IS a problem. If someone forgets to get the latest or, worse, changes an interface WITHOUT COMPILING AND CHECKING IN THE BINARY (I capitalized this because it is easy to forget) all the compatibility breaks right away. Usually we call each other when a change as been made in an interface, but things get messy once in a while. Not for nothing this problem is calles DDL Hell...
Rule of thumb: get the latest in the morning before start working, and hope that everyone is virtuos :-)

John's statement (all classes in one DLL) leaves me perplexed. We have dozens of servers, dlls and ocx in our application (written in both C++ and VB), it would be problematic to fit all classes in one object (besided going against the concept of distribuited components) But I agree that it is much better to put shared coded in one component. You start with one shared Form, and soon as the projects goes that form start using external classes, modules or dlls. Every change in that form breaks all the other projects that use it! Shared coded must be simple and self contained (like constant definitions or simple methods) Well, I am going to far here, sorry for this long post ;)

Marco