How to do development and build in visual basic 6.0

Question

I am looking for best practice in building multiple visual basic projects(all dll's).We have multiple projects, and our final deliverable will be a dll.Now, one project uses 2 other projects, and another refers to another project.Should projects reference the vbp files, or the dll? If they reference vbp files, how to build all the projects?

Answer 1

Unless you are specifically managing the type libraries externally from VB, you should use project references. If you reference the files, and you modify the public interface in various ways VB will generate new id's for various pieces in the typelibrary which will result in type mismatch errors.

You can use the Preserve Compatability settings to help alleviate this. Make sure your using at least project level (If your doing COM+ then you'll want binary the one based on an already compiled version of the dll)

As for compiling, you can compile a solution file (been a long time since I even had Vb6 installed but I think they were .vbg files).

Back in the day we used Visual Build, and also Visual Make which supported compiling the solution files.

Answer 2

You compile each project separately starting at the lowest level and working your way up the chain.

The big problem of builds with VB6 generally goes back to compatibility issues. The worst case compatibility problems the fix goes something likes this

Build A (with A being the one all the others reference)

Copy A into the compatibility directory

Build B that reference A

Copy B into the compatibility directory

Build C that references B and A

Copy C into the compatibility directory.

and so on.

This is because the typelibs of the COM DLL uses INCLUDE to add in the typelibs of the projects they reference. You can see the Type Libs of a VB6 COM DLL by using the OLE View tool that comes with Visual Studio 6.0.

Many times adding methods or properties will cause the DLL to fail to compile because MS Method of setting up the Typelibs renders them not binary compatible. This fails when the addition is otherwise permitted under the rules of binary compatibility.

The solution that works 90% of the time is to always put the newest version of the DLLs being reference in the compatibility directory.

Once you have a good set you can have a automated builder use it to build the project automatically.

Note that this issues occurs only when you add something that other DLLs reference and they need to maintain binary compatibility.

You need a system of making sure everybody has the correct set of compatibility DLLs to build against.

Answer 3

After some years with VB6, our projects tended to be structured like this:
All project source (project and source) organized under the source folder.
\project\source
\project\source\project1\
\project\source\project2\
...
All binaries (.dll and .exe) in one bin folder.
\project\bin\

All .dll set as binary compatible with resulting file in the single bin diretory.

After initial build to make the binarycomptible stable, every non breaking build would be done by using a simple command file build.cmd placed in the folder above the source folder, maybe like this:
"c:\Program Files\Microsoft Visual Studio\VB98\VB6.EXE" /M .\source\project1\proj1.vbp
"c:\Program Files\Microsoft Visual Studio\VB98\VB6.EXE" /M .\source\project2\proj2.vbp
"c:\Program Files\Microsoft Visual Studio\VB98\VB6.EXE" /M .\source\project3\proj3.vbp
del .\bin\*.exp
del .\bin\*.lib

The build order must be in the order of dependance.
Whenever a breaking change occured, the dependant VB project must be refrenced to the new binary.
Without breaking changes, the build.cmd usually did the job.