Ferengi February 2016

Definitive/Guaranteed Approach to Execute Batch Script Post MSI Installation using Visual Studio 2013

I've been cobbling some post installation steps but having difficulties, which I will go into. Please recommend a suitable, ideally native, process to run some custom steps post installation.

Using: Visual Studio 2013 Ultimate

Setup: vb.NET project & Visual Studio Instillation Project

Test OS: Win 7 x64 with Admin

Currently, installer successfully install main application and extracts MS SQL Express + SQL scripts to a subdirectory. I have a batch file ("InstallSQL.bat") in the same directory, which silently installs SQL Express, and then executes the SQL scripts.

So how to best execute the "InstallSQL.bat" script, when Visual Studio doesn't support batch execution, from an installer Custom Action?

Methods I've tried:

  1. Add cmd.exe (32-bit & 64-bit) + Installer Custom Action to launch the script, as per this post. For some reason, the cmd.exe is executed with non-administrator credential, and SQL Setup fails.

  2. Use a VBS script, to launch the batch script. VBS script does not run and error "A script required for this install to complete could not be run".

I am happy to consider an alternative approach to install SQL Express and run scripts, not based on a batch file. However, my custom batch file works perfectly when run manually i.e. not from the installer.

Please note, it needs to work on Windows XP and up, be location insensitive i.e. no static file locations and ideally, without using 3rd party utilities. This last requirement is weak.

Answers


RGuggisberg February 2016

I do that with a config file

"YourSQLExeFile" /CONFIGURATIONFILE="FullPath\YourConfigFile"

You did not specify what version of SQL you are using (2008/2012/2014, etc). You can find examples with a google search... otherwise I may be able to share what I use if you reply with SQL version.


PhilDW February 2016

This is all so error prone your best bet is to do it as part of the configuration of the app when it first runs.

Any custom action code that runs with user credentials (typically because it is a "just me" install) will not run elevated.

Any custom action code that runs in a per machine Everyone install will run elevated with the system account, which typically is not helpful because the system account doesn't have database credentials or network credentials (if the database is on a network share it doesn't work).

If your vbscript fails you'll need to do the install with a verbose log to get diagnostics. A common error is to use the WScript object, but that's available only if you initiate the script with WSH, and Windows Installer is not WSH.

This is why it's better to do it after the install, initiated by the user rather than by an msiexec process running with the system account or impersonating the installing user.

You best hope of doing this from the install is for you to write code to read that script and configure the database. The SQLCommand class, for example, as here:

Sql Scripot with C#

Run SQL script

Run a SQL Script

This executable needs a manifest requesting administrator privilege so when it runs it prompts for elevation. You fire off this program from your VBScript custom action. The point is that this elevation and the fact that it's shell-executed as a separate process gives some independence from the msiexec.exe service process that is calling your custom actions. Again, Everyone vs. Just me installs will mak

Post Status

Asked in February 2016
Viewed 3,586 times
Voted 13
Answered 2 times

Search




Leave an answer