Silent Installs and Visual Basic 6 Setup Packages

It's hard to believe that people are still distributing their products written in Visual Basic 6.

As a system administrator responsible for pushing software to thousands of servers and desktops, setup programs frustrate me when:

1. There is no way to do a silent install
2. There is a silent install and some condition causes it to not be silent

In order to distribute installations to machines in any automated fashion (or even manual installs that you want done consistently), an installer MUST be able to perform silently.  If it can't, it's no good to me and I have to build my own custom installer.  

One of the most offending installations are Visual Basic 6 setup packages.  These packages, by default, have a setup file that can be installed silently.  That is great!  The problem is, most VB6 Setup packages contain old, outdated files that we don't need to update on our machines (in this century!), but the installer doesn't provide a mechanism to tell it to skip these files.

You've all seen it -- it's that window that pops up saying that some file is newer than the one in the setup, and it's asking you if you would like to overwrite it.  

You can find silent installation instructions all over the internet.  You simply add a -s<logfile> to the setup.exe and it installs silent.  An example command line would be:

SETUP.EXE -SC:\Logs\myprogram.log

This, by definition, should install the application without prompting the user for any information.  Unfortunately, if the setup contains a file from 1998, it's going to prompt you to overwrite it.  This breaks all automated installation methods.

To get around it, you can follow these steps:

Find the offending file:

You must run through the installation at least once.  It should ask you if you want to overwrite a file.  Write down that filename!  Continue the setup, as there may be more than one file.

Remove the file from the installer:

There is a special file in the setup package called SETUP.LST.  This is a INI file that tells the installer how to behave.  Open this file with notepad and find the [Setup1 Files] (the heading may be slightly different) section.

Under this section, you should see a bunch of almost meaningless information.  However, you should be able to locate the file that was causing you problems.  You'll see something like this:

[Setup1 Files]
File1=@MSINET.OCX,$(WinSysPath),$(DLLSelfRegister),$(Shared),5/22/00 2:00:00 AM,115920,6.0.88.62
File2=@XUpload.ocx,$(WinSysPath),$(DLLSelfRegister),$(Shared),2/16/00 1:48:48 AM,210256,1.0.0.2
File3=@CCRPPRG6.OCX,$(WinSysPath),$(DLLSelfRegister),$(Shared),8/3/99 2:12:58 PM,102400,1.20.0.263
File4=@CCRPFTV6.OCX,$(WinSysPath),$(DLLSelfRegister),$(Shared),10/30/99 2:00:00 AM,167936,1.0.0.6
File5=@Mscomctl.ocx,$(WinSysPath),$(DLLSelfRegister),$(Shared),3/27/01 12:32:28 PM,1066176,6.0.88.62
File6=@xceedzip.ocx,$(WinSysPath),$(DLLSelfRegister),$(Shared),3/24/98 12:00:00 AM,167424,3.1.0.3



In my case the file was mscomctl.ocx.  I don't want the installer to do anything with the file because the one
on my machines are going to be newer than the one written in 2001, and I know it's going to be on every machine I will ever deploy this to.  If it's not, the installer could fail, but that is on me.

To fix it so this installer actually does a silent install -- just remove the offending line and adjust the number accordingly.  See below for the edited version that did the silent install:

[Setup1 Files]

File1=@MSINET.OCX,$(WinSysPath),$(DLLSelfRegister),$(Shared),5/22/00 2:00:00 AM,115920,6.0.88.62

File2=@XUpload.ocx,$(WinSysPath),$(DLLSelfRegister),$(Shared),2/16/00 1:48:48 AM,210256,1.0.0.2

File3=@CCRPPRG6.OCX,$(WinSysPath),$(DLLSelfRegister),$(Shared),8/3/99 2:12:58 PM,102400,1.20.0.263

File4=@CCRPFTV6.OCX,$(WinSysPath),$(DLLSelfRegister),$(Shared),10/30/99 2:00:00 AM,167936,1.0.0.6

File5=@xceedzip.ocx,$(WinSysPath),$(DLLSelfRegister),$(Shared),3/24/98 12:00:00 AM,167424,3.1.0.3

After editing, make sure you save.  The installer should now skip over the offending file and you can use the -s>logfile< parameters to push the application "silently".  

Remember, if you strip a reference out of this file, then you may be actually breaking the application.  You should do enough testing to feel comfortable that this isn't going to break the application!