Image Map of Navigational Panel to Home/Contents/ Search Distributing Applications Developed with VB

by Dan Appleman - Desaware

Image of line

Quite a bit of attention has been paid lately to the problem of source code control and group project management. Fortunately, a number of source code control projects have begun to appear. It is only recently that developers have turned their attention to the problem of safely distributing applications that make use of components such as Visual Basic custom controls (VBXs) and Dynamic link libraries. The presence of an obsolete component on a system can cause an application to fail, and even cause a General Protection Fault.

Developers have attempted a number of solutions. Some try to place their VBXs and DLLs in their own application directory. This approach can fail in two ways. First, once another application loads a different version of the control, that version will be used - Windows will not attempt to load the correct version. Next, it is not possible to guarantee that the current directory will be the same as the one containing the components, and Windows always searches the current directory first. Some developers attempt to make sure that they have the correct control by installing their versions of a component into the system directory regardless of the presence of an existing control that may have a later version. This could almost be considered criminal, as it is likely to break other applications on the end user's system.

Windows searches for components in the following order:

  1. Any component with the same module name that is already in memory.
  2. The current directory.
  3. The Windows directory.
  4. The System directory.
  5. The project directory (contains the executable that is loading the component).
  6. Directories specified by the PATH environment variable.

There is no way to completely assure that an incompatible control does not exist somewhere on a target system, or to prevent it from being loaded.

Worse yet, there is no way to determine the version of a Visual Basic executable, as VB does not support standard Windows version resources. This means that a user could take an older version of your application, and overwrite a later version without warning.

Given these facts, Two things are clearly needed. First, a way to embed a version resource into a VB executable. Second, a way to mark an executable with a list of the components that it requires so that it would be possible to determine if the correct components are in fact present on a target system. Desaware's new Version-Stamper-VB addresses both issues.

For details on Products manufactured by Desaware, download GUI Computing's Catalogue, 756KB in size.

Written by: Dan Appleman
June 94

Image of arrow linked to previous page Image of arrow linked to next page
Image of line