Conflicts are not always as easy as two files with different versions, size or date. A less often encountered conflict involves two files installed in the same directory, but with different GUIDs. This problem is not usually discovered until on of the applications is uninstalled, breaking the remaining application.
I am working with a department that at one time called on a VB 6 developer to build a number of queries. He did a great job with a nice interface, a drop down pick list that covered all the options, and it returned formatted data. The problem was that each time he compiled an application, the GUIDs were regenerated for the same files. He did this 7 times, and when one of the applications was uninstalled, 30 people were sitting on their hands wondering what went wrong with their PC. Finding the source of the problem after the fact takes a considerable amount of detective work. If these applications were repackaged and run through a Conflict Manager Database this type of problem could have been addressed long before it cause a departmental outage. Even without a good Conflict Manager tool, there are some things to look for, if you know where to look. Below is a little background information that may help.
Within Visual Basic 6, there is a "Microsoft Packaging and Deployment Wizard". Like all Wizards it simplifies a complex task into a few Windows that all you need do is click 'Next' to create a standard installation and screw up as many desktops as you like. Take a look the "Setup.lst" file that is generated by the Wizard. The Setup.lst file describes all the files that must be installed on the machine for the application.
There are five sections to the Setup.lst file:
The BootStrap section — lists the core information about the application, such as the name of the main setup program for the application, the temporary directory to use during the installation process, and the text in the startup window that appears during installation.
The BootStrap Files section — lists all files required by the main installation file. Normally, this includes just the Visual Basic run-time files.
The Setup1 Files section — lists all other files required by your application, such as .exe files, data, and text.
The Setup section — contains information needed by other files in the application.
The Icon Groups section — contains information about the groups your installation process will create. Each member of this section has a correlating section containing the icons to be created in that group.
The Setup1 section lists all other dependencies and any other files that have been added to the Setup package. It's the Setup1 section that usually produces errors like this one because the files versions and dates are fixed as of the date the installation was built and the versions of files on the developers workstation.
If you are not sure about what the dll is for or what the correct version is, go to http://support.microsoft.com/dllhelp
(if this site isn't on your favorites list add it).
Translating a SETUP.LST file created with the P&D wizard
The Setup1 Files section contains all the other files required by your application, such as your .exe file, data, text, and dependencies. The setup program installs these files after it installs the core files listed in the Bootstrap Files section.
The following example shows entries in a typical Setup1 Files section:
[Setup1 Files]
File1=@LotsAControls.exe,$(AppPath),$(EXESelfRegister),,1/26/98 3:43:48 PM,7168,1.0.0.0
File2=@mscomctl.ocx,$(AppPath),$(DLLSelfRegister),,1/23/98 9:43:40 AM,1011472,6.0.80.23
Filex= file,install,path,register,shared,date,size[,version]
Filex - A keyword that must appear at the beginning of each line. X is a sequence number, starting at 1 in each section and moving in ascending order. You cannot skip values.
File - The name of the file as it will appear after installation on the user's computer. This is usually the same as the Install argument. If you want this file to be extracted from a cab, place an @ at the beginning of the name (for example, @my.exe).
Install - The name of the file as it appears on any distribution media.
Path - The directory to which the file should be installed. Either an actual directory path, a macro indicating a user-specified path, or a combination of the two. See "Path Argument Macros in Setup.lst Files" later in this chapter for more information on the available macros.
Register - A key that indicates how the file is to be included in the user's system registry.
Shared - Specifies that the file should be installed as shared.
Date - The last date on which the file was modified, as it would appear in Windows Explorer. This information helps you to verify that you have the correct versions of the files on the setup disks.
Size - The file size as it would appear in Windows Explorer. The setup program uses this information to calculate how much disk space your application requires on the user's machine.
Version - An optional internal version number of the file. Note that this is not necessarily the same number as the display version number you see by checking the file's properties.
Translating the VB constants/flags:
$(AppPath) - {app} constant
$(WinSysPathSysFile) - {sys} constant
$(WinSysPath) - {sys} constant
$(DLLSelfRegister) - regserver flag
$(Shared) - sharedfile flag
$(TLBRegister) - regtypelib flag
$(MSDAOPath) - {dao} constant
$(EXESelfRegister) -use the [Run] section
for "MyApp.exe /RegServer"
use the [UninstallRun] section
for "Myapp.exe /UnregServer"
For more information on this subject see
Comments