One of the things that everyone who writes installers hears about writing installers is that a user’s first impression of your product comes from the installer. Anything in the installer that startles the user or causes the user to regret clicking that fifth Next button is an opportunity for improving the user’s first impression of your product.
As a user of installations, one thing that makes me jump when I run an installer is seeing a command prompt window pop up.
Whenever it happens, I picture the publisher’s QA department creating a batch file for testing the product, and the install developer wanting to leverage what’s already in place. (Back when Windows Installer was introduced, the Windows® logo guidelines required a product’s installation to use Windows Installer. A common first reaction was, “I can just take my existing installer, and run it as an MSI custom action. Problem solved!” This is the same idea.) Being able to connect disparate processes to achieve a goal is an admirable skill. But in this case, don’t do it.
An opportunity exists for someone to write a Windows Installer ICE rule that fails if a custom action launches cmd.exe.
Instead of launching the command processor or a batch file to do something in your installation, you should see if built-in installer functionality can replace what the batch file does. Both Windows Installer and InstallScript have functionality for performing actions it can be tempting to use batch files for:
- Instead of running regsvr32 to register a COM server, you can extract COM information or use component properties and functionality.
- Instead of running net start to start a service, you can use MSI component advanced settings or InstallScript functions.
- Instead of deleting extra files on uninstall using a batch file, you can use MSI tables such as RemoveFile or use InstallScript functions.
- Instead of manipulating text files from a batch file, InstallShield has functionality for working with text files and XML files as well as InstallScript functions for manipulating files.
System changes made by built-in installer functionality are usually easier to uninstall or roll back than changes made by a batch file or other type of custom action. And if you must launch a system executable, you can often launch it directly rather than going through a batch file.
Smoothing out your installation’s user interface is work that’s repaid by an improved overall user experience for your product.
