To launch a batch file from a custom action, you can’t just specify the .bat file as the executable to run; instead, you can launch cmd.exe or command.com, depending on the platform, with the path to the batch file as an argument. Instead of hard-coding the path to the command processor—which plenty of people seem to think is just fine—you can expand the COMSPEC environment variable and launch the result.
There’s probably a better way, but a two-step process for launching a batch file that you’re installing is:
- Create a Type-51 (set a property) custom action, with source COMSPEC and target [%COMSPEC]. It should be an immediate-mode custom action that goes somewhere in the Execute sequence.
- Next, create a Type-50 (launch an executable whose path is in a property) action with source COMSPEC and target /c "[INSTALLDIR]LaunchMe.bat" (or whatever the path to the file is). This should be a deferred action (add 1024 to the type), possibly without impersonation (add another 2048, for a grand total of action type 3122), scheduled after InstallFiles (since it’s a file you’re installing).
Pop quiz: why can’t we just get rid of the first action and use [%COMSPEC] in the source of the second action?
As usual, to run the actions only during the initial installation, give the actions the condition Not Installed, or, better yet, use the $ComponentName=3 type of condition.
(At this point, I might as well admit that I don’t know an automatic way to hide the command prompt window.)
Keep in mind that you don’t need to launch a batch file to launch something that’s already in the form of an executable. For example, I’ve seen installers that launch a batch file just to run net.exe or attrib.exe. I’ve seen things you wouldn’t believe.