kinook
04-08-2003, 10:49 AM
Visual Basic 6.0 provides quite a bit of support for creating VB COM components (ActiveX DLLs, Controls, and EXEs), but if you're not careful the compatibility issues can cause a lot of headaches. We will give some recommendations and also explain how the Make VB6 action can help out.
For serious VB development, consider taking the compatibility issues out of VB's control by using the IDL method for defining your interfaces. <a href="http://www.yukondude.com/articletamevbwithidl.asp">This article</a> gives a good explanation of how to achieve this. It takes some effort up front, but in the long-term you will see a big productivity benefit, because compatibility/reference problems are virtually eliminated. If you follow this method, you can always leave your projects set to binary compatibility, and you can also use the 'Exclude references when determining the need for incremental builds' option to speed up your builds even more than normal (if building with project or no compatibility, the date/time of referenced projects must be taken into account to determine what needs to be built, but this is unnecessary for binary compatibility builds).
If you can't go the IDL route, Visual Build's Make VB6 (http://www.kinook.com/VisBuildPro/Manual/makevb6.htm) action does provide the features necessary to maintain your sanity:
<ul>
<li>The compatibility settings of your projects are very important. The setting is configured at Project | Properties | Component on the VB menu. It determines how VB handles the project's GUIDs (which are used to identify classes [CLSID], interfaces , and type libraries [TLID]).</li>
<li>Use the [i]Binary compatibility setting whenever possible. This causes all GUIDs to be retained with each build, and minimizes registry clutter and reference problems. The Make VB6 action provides options to automatically set a project to binary compatibility after building (you can also use in conjunction with the 'no build' option to set projects to binary compatibility before building). Use the binary compatibility option flag so your developers don't have to remember to set this property every time they add a new project to the build.</li>
<li>Use the Project compatibility setting when you need to break compatibility on a project. This is necessary when you modify the signature of a class or control (by adding, modifying, or removing methods). Using project compatibility causes the class and interface GUIDs to be regenerated, but only increments the type library version (retaining the GUID) and won't break references to the project (the referencing projects will need to be rebuilt, but the Make VB6 action considers the timestamp of all referenced executables and rebuilds if necessary). You can use the project compatibility option to set all projects to project compatibility before building on those occasions when you need to break compatibility.</il>
<li>Avoid using the No compatibility setting. This causes all GUIDs in the project to be regenerated each time the project is built. This includes the typelib GUID, which is what VB uses to keep a reference to another project, and can lead to missing/broken references. The Make VB6 will actually fix up references (within the group) for projects built with no compatibility.</li>
</ul>
Because VB compatibility uses the typelib information in each project's executable, the executables should be registered before building in order for the builds to succeed. You can either:
<ul>
<li>Build each project once in the IDE (and save the project) to set the target output path, store the projects and executables in source control, check them out and register them at the start of each build (use the Process Files macro--see the Recurse.bld sample), and check in the updated executable after building, or<br>
<li>Build the projects once in the IDE on the build box when initially setting up the box (saving each project and updating in source control, but not placing the executables in source control). If the build box needs to be recreated or the compatible executables are lost, the project references will need to be updated manually in Visual Basic. It is a good idea to keep a backup of the most recent executables in order to avoid this problem.
<li>If you don't build once manually and save the projects, the executables will be created in the directory of each VB project. When updating references within a project group, the Make VB6 action will even detect project references that point to another project that hadn't been compiled (Visual Basic stores this as the VBP filename) and updates the reference to point to the new executable's typelib after the referenced project gets built the first time.
</ul>
For serious VB development, consider taking the compatibility issues out of VB's control by using the IDL method for defining your interfaces. <a href="http://www.yukondude.com/articletamevbwithidl.asp">This article</a> gives a good explanation of how to achieve this. It takes some effort up front, but in the long-term you will see a big productivity benefit, because compatibility/reference problems are virtually eliminated. If you follow this method, you can always leave your projects set to binary compatibility, and you can also use the 'Exclude references when determining the need for incremental builds' option to speed up your builds even more than normal (if building with project or no compatibility, the date/time of referenced projects must be taken into account to determine what needs to be built, but this is unnecessary for binary compatibility builds).
If you can't go the IDL route, Visual Build's Make VB6 (http://www.kinook.com/VisBuildPro/Manual/makevb6.htm) action does provide the features necessary to maintain your sanity:
<ul>
<li>The compatibility settings of your projects are very important. The setting is configured at Project | Properties | Component on the VB menu. It determines how VB handles the project's GUIDs (which are used to identify classes [CLSID], interfaces , and type libraries [TLID]).</li>
<li>Use the [i]Binary compatibility setting whenever possible. This causes all GUIDs to be retained with each build, and minimizes registry clutter and reference problems. The Make VB6 action provides options to automatically set a project to binary compatibility after building (you can also use in conjunction with the 'no build' option to set projects to binary compatibility before building). Use the binary compatibility option flag so your developers don't have to remember to set this property every time they add a new project to the build.</li>
<li>Use the Project compatibility setting when you need to break compatibility on a project. This is necessary when you modify the signature of a class or control (by adding, modifying, or removing methods). Using project compatibility causes the class and interface GUIDs to be regenerated, but only increments the type library version (retaining the GUID) and won't break references to the project (the referencing projects will need to be rebuilt, but the Make VB6 action considers the timestamp of all referenced executables and rebuilds if necessary). You can use the project compatibility option to set all projects to project compatibility before building on those occasions when you need to break compatibility.</il>
<li>Avoid using the No compatibility setting. This causes all GUIDs in the project to be regenerated each time the project is built. This includes the typelib GUID, which is what VB uses to keep a reference to another project, and can lead to missing/broken references. The Make VB6 will actually fix up references (within the group) for projects built with no compatibility.</li>
</ul>
Because VB compatibility uses the typelib information in each project's executable, the executables should be registered before building in order for the builds to succeed. You can either:
<ul>
<li>Build each project once in the IDE (and save the project) to set the target output path, store the projects and executables in source control, check them out and register them at the start of each build (use the Process Files macro--see the Recurse.bld sample), and check in the updated executable after building, or<br>
<li>Build the projects once in the IDE on the build box when initially setting up the box (saving each project and updating in source control, but not placing the executables in source control). If the build box needs to be recreated or the compatible executables are lost, the project references will need to be updated manually in Visual Basic. It is a good idea to keep a backup of the most recent executables in order to avoid this problem.
<li>If you don't build once manually and save the projects, the executables will be created in the directory of each VB project. When updating references within a project group, the Make VB6 action will even detect project references that point to another project that hadn't been compiled (Visual Basic stores this as the VBP filename) and updates the reference to point to the new executable's typelib after the referenced project gets built the first time.
</ul>