Share via

Visual Basic Concepts

  • Article

Allowing the User to Remove Your Application

When the user installs your application, the setup program copies the application-removal utility St6unst.exe to the \Windows or \Winnt directory. Each time you use the Visual Basic setup program to install an application, an application removal log file (St6unst.log) is generated in the application's installation directory. The .log file contains entries indicating:

  • Directories created during installation.

  • Files installed and their location. This list contains all of the files in the setup program, even if some files were not installed on the user's machine because a newer version of the same file already existed. The log file indicates whether the file was a shared file and if so, whether it replaced the existing file.

  • Registry entries created or modified.

  • Links and Start menu entries created with Windows 95, Windows NT 4.0, or later systems.

  • Self-registered .dll, .ex, or .ocx files.

In Windows 95, Windows NT 4.0, or later systems, the setup program adds the application removal utility to the list of registered applications displayed in the Add/Remove Programs section of Control Panel. End users should use Add/Remove Programs to uninstall the application.

Caution   It is important to make sure that you have correctly set options for any files that should be shared, either by adding the files to the Shared Files screen in the Package and Deployment Wizard, or by indicating the installation location for the file as a shared file directory. If you accidentally install a file that should be shared without the correct settings, users will be able to remove it when they uninstall your application, which may cause problems for other applications on your system.

In the event of a failed or canceled installation, the application-removal utility automatically removes all of the directories, files, and registration entries that the setup program created in the installation attempt.

With Windows 95 or later and Windows NT, shared files are reference-counted in the registry. For example, a shared file used by three applications will have a reference count of three. When you remove an application that uses a shared file, the reference count for the shared file decreases by one. When the count for the file reaches zero, the user will be prompted for final removal of that item.

Situations in Which the Application Removal Utility Might Fail

For the application-removal utility to properly uninstall your application, the log file and registry entries created by the setup program must be accurate and unchanged from the time of installation.

The Application Removal utility might fail or work incorrectly if any of the following situations exists:

  • The end user copied shared files manually. In this case, reference counting is not updated in the registry, so the system cannot correctly judge when to remove the file.

  • The end user deletes installed files or an application directory rather than using the application-removal utility. This deletes the log file, so that application removal is impossible. In addition, it makes it impossible to remove system registry entries for program files, DLLs, or .ocx files in the application directory because these files must be run in order to be removed.

  • A setup program for an application that is not compliant with Windows 95 or later installs the same shared files as does your application.

  • A shared file is installed into a different directory than the one in which it already exists on the hard drive.

  • The end user installs the same Visual Basic application in two different directories. Not only will the first installation no longer work, but the application removal scenarios will clash. The end user should always remove the first installation before installing an application in a different directory.

  • The end user deletes the application setup log (St6unst.log). Without the application setup log file, the application-removal utility has no installation information and will fail.

Some of these scenarios could degrade the installed file-registry correspondence, cause the Application Removal utility to prematurely reach a zero-reference count for a particular file, and subsequently ask if this file could be deleted. If a file is prematurely deleted, it could cause other applications to cease functioning or function incorrectly due to missing file dependencies, missing components, and so on.