Vb6 project files and source safe

Question

A part of the application that I am working on is a legacy Vb6 Windows forms application. All the files in the project are under source control (VSS) except the Vb6 project file. From what I can establish from the other developers working on the project the reason for this is that the com components used in the projects have different references on each developers machine. I want to move the project files into VSS so that when files are added to the project these can be updated in the project files and other developers (and more importantly an automated build script) can get the latest project files from source safe.

Does anyone know if/how I can achieve this in such a way as to not corrupt the references to other com components on different development machines?

Answer 1

Long story short, no.

The real problem is that developers are not getting their COM components from the same place, either because they are compiling them locally, or they are obtaining different versions of the same component. If the COM objects are not in constant development, the real solution is to have all the developers install the same version of the components they need.

Answer 2

I don't agree your colleagues. If each developer requires different references on their machine I am willing to bet you've got some strange usage of COM types going on. Most likely you have CoClass types and Interface types compiled into your dlls.

COM is all about separating interface from implementation (even though VB6 does it's best to undo that by creating default interfaces for each CoClass and not telling you about them). Move your types into a TLB type library and reference that in your projects. Let the COM registration on each machine handle what specific classes are instantiated; that's what it is there for.

If your team is struggling with COM references this much something deeper is wrong.

Answer 3

You need to maintain a standard that describes your development projects folder structure. For instance, I always recommend creating a substitue drive SUBST. Such as SUBST H: C:\DEV_\APP\Visual Studio 2008. This allows the developer to put his stuff where he needs. In this "new" drive, I recommend a "system" folder. Each COM object and dependencies are placed into a sub-folder. All project reference the COM objects only from H:/System/. Different COM versions go into a new with the version as part of the folder's name. For instance, C:\DEV_\APP\DEV\SYSTEM\Iocomp and C:\DEV_\APP\DEV\SYSTEM\Iocomp2.

(Don't forget to register the COM objects from the correct path, the "new" drive.)

I use a batch file on startup to set four differnt development drives.

The nice thing about using SUBST, is you can check-out to a different folder then create an "H" drive to that folder and everything works.

I been using this technique since 1996 to very good effect. I never have any problems. The hardest part is getting others introduced to the technique.