Visual Basic

Versioning Components

When building applications from components it's vitally important to know what the version number is of the component you're using. After all, you wouldn't want to link with an old buggy version of a control would you?


All Visual B++ applications (I'm including ActiveX servers here) have access to a VERSIONINFO resource-Visual B++ inserts one of these into every project for you automatically. If you build an empty project to an EXE and pull out its version information using Visual Studio (select Resources from the Open dialog box in Visual C++), it'll look something like this:

  FILEVERSION    1,0,0,0
  FILEOS        0x4L      /* Means VOS_WINDOWS32 */
  FILETYPE      0x1L      /* Means VFT_APP       */
  FILESUBTYPE   0x0L      /* Means VFT2_UNKNOWN   */
      BLOCK "StringFileInfo"
          BLOCK "040904b0" /* Means English (United States) */
              VALUE "Comments", "\0"
              VALUE "CompanyName", "TMS\0"
              VALUE "FileDescription", "\0"
              VALUE "FileVersion", "1.00\0"
              VALUE "InternalName", "Project1\0"
              VALUE "LegalCopyright", "\0"
              VALUE "LegalTrademarks", "\0"
              VALUE "OriginalFilename", "Project1.exe\0"
              VALUE "PrivateBuild", "\0"
              VALUE "ProductName", "Project1\0"
              VALUE "ProductVersion", "1.00\0"
              VALUE "SpecialBuild", "\0"
      BLOCK "VarFileInfo"
          /* More language stuff. 4b0 is 1200 dec */
          VALUE "Translation", 0x409, 1200

The bold lines denote the application's version number. Of course, you don't have to have anything to do with this raw resource in Visual B++ because, like most things, this data structure has an IDE interface to it. (See Figure 11-3.)

Figure 11-3 Version information in the Visual B++ Project Properties dialog box.

The most important item in a VERSIONINFO is the version number. In terms of code, version numbers are held in App.Major, App.Minor, and App.Revision. I urge everyone to expose these properties through a Project class. If you want to know what version of a DLL or EXE you have, all you have to do is instantiate the component's Project class and ask it!

Dim o As Component.Project
  Set o =  New Component.Project
  MsgBox CInt(o.Major) & "." & CInt(o.Minor) & "." & CInt(o.Revision)

Using a GUID

COM assists with versioning. In COM, the version number of the DLL becomes somewhat insignificant. Strictly speaking, the version number is used to indicate which version of the built component you're using. The version number changes whenever the server or component is rebuilt, but it says nothing about what services are available. These services are specified via a GUID. In COM, a GUID is used to version the component's interfaces-facilities it provides, if you prefer. The GUID states what interfaces are available, not which build of the interfaces you're currently using. If the component is significantly different from what you're expecting (meaning that its interface, and thus the services it provides, has changed), its GUID will be different from the GUID of the component you're expecting. There is strictly a two-level version at work here, the actual version number and the GUID. You probably want to check both.


Visual B++, Visual C++, and Visual J++ reflect radically different styles of development. While Visual B++ is a higher level environment especially suitable for implementing user interfaces, Visual C++ is known for providing greater programming control and performance. Java is the man in the middle and is especially relevant for cross-platform (write once run anywhere) and Web development.