You had me at "Hello World" : Setup Project

How to Add Command Line Support with Your .MSI

HelloWorld — Fri, 06 Feb 2009 21:23:59 GMT

One of the requirements in building setups was to allow the Operations team to execute the .msi file from the command line. GUI is not for expert! :)

If you are familiar with Visual Studio setup, each of the UI element has a property, and you pass this property to your custom action, or use it as condition in your setup (whether to install the documentation, help, or whether to install to the gac or not, etc.).

msiexec.exe allows you to pass some parameters to override those properties. Unfortunately the .msi file that Visual Studio generates always set the default values, default value being the values that the developers set during design time.

After inspecting the .msi, there are some custom actions that will set the property value to the default. This custom actions are always executed, whether the users sets the property via command line parameter or not. That means, if the user pass some parameters to override the property, the setup will execute the custom action, reassign the property value to the original default value.

So what needs to be done is to prevent the custom action from executing when the property is overridden by the user. This can be done quite easily with text box dialogs, checkbox dialogs are a little bit more difficult, I will cover it in other post.

The property has blank value/null in the beginning, if the user overrides the property via command line parameter, this value will not be null. By giving custom actions a condition, to execute only if the property is blank, the value that the user gave via command line will not be overridden.

You need to set the conditions in two different tables in your .msi file, InstallExecuteSequence and InstallUISequence. One to support GUI mode (interactive) and the other to support quiet/passive mode.

This is the example on how to do it, repeat the steps for every property that you want to be able to override:

Identify the property that you want to override. From within Visual Studio, writes down the property that you want to be able to override. For example, you set a property SERVERNAME, related to Edit1Property on Textboxes (A), and the default value is 'DefaultServerName'.
Check the InstallUISequence and InstallExecuteSequence tables in the .msi using Orcas, you should see something like this:

You know this is the action that you want from the Action name, it is CustomTextA, corresponds to the Textboxes (A), and it is the Edit1 control. If you check the CustomAction table, you will see something like this:
To prevent the custom action from executing, add this condition on both InstallUISequence and InstallExecuteSequence tables, SERVERNAME = "".

This tells, if the SERVERNAME is blank (the user did not override), execute the custom action to assign the default value. Please pay attention that the condition is for an empty string (two double quotes).
Save the .msi and close Orcas.
Execute the .msi using this command:
msiexec /i [The msi name].msi SERVERNAME="HELLOWORLDSERVER"

After executing those steps, the UI will show HELLOWORLDSERVER in the text box.

To set this condition automatically as part of your build process, we need to use a script to modify the setup. This can be done by setting the post build event for your project.

Create a .js script. Call it CommandLineSupport.js, repeat the update statement for every property that you want to be able to override.
//This script adds command-line support for MSI build with Visual Studio 2008.
var msiOpenDatabaseModeTransact = 1;

if (WScript.Arguments.Length != 1)
{
    WScript.StdErr.WriteLine(WScript.ScriptName + " file");
    WScript.Quit(1);
}

WScript.Echo(WScript.Arguments(0));
var filespec = WScript.Arguments(0);
var installer = WScript.CreateObject("WindowsInstaller.Installer");
var database = installer.OpenDatabase(filespec, msiOpenDatabaseModeTransact);

var sql
var view

try
{
    //Update InstallUISequence to support command-line parameters in interactive mode.
    sql = "UPDATE InstallUISequence SET Condition = 'SERVERNAME=\"\"' WHERE Action = 'CustomTextA_SetProperty_EDIT1'";
    view = database.OpenView(sql);
    view.Execute();
    view.Close();

    //Update InstallExecuteSequence to support command line in passive or quiet mode.
    sql = "UPDATE InstallExecuteSequence SET Condition = 'SERVERNAME=\"\"' WHERE Action = 'CustomTextA_SetProperty_EDIT1'";
    view = database.OpenView(sql);
    view.Execute();
    view.Close();

    database.Commit();
}
catch(e)
{
    WScript.StdErr.WriteLine(e);
    WScript.Quit(1);
}

Save the CommandLineSupport.js in the same folder with your setup project file, and set PostBuildEvent for the setup project.

Make sure .msi name matches your .msi file name.
Build the project.

Standard disclaimer applies, no warranty, use it at your own risk, always test the changes. Wow, this post is longer than what I thought it would be....

CustomActionData and User Defined Path

HelloWorld — Tue, 08 Apr 2008 06:11:52 GMT

When designing a setup project, you can define text boxes dialog to input a file system path. To process the input that the user has entered, usually a custom action is created to handle the user input, and the user input is passed through CustomActionData property. Unfortunately, there are several problems when dealing with path.

Spaces in the path
A space is a valid character for a path. If the user passes a path with a space in it, you should enclose the input with double-quotes, for example, this is a CustomActionData property value: /USERDEFINEDDATA="[USERPATH]".
This leads to a different problem below.
Backslashes trimmed.
When the user enters a UNC path starting with "\\", if the value property is enclosed with double-quotes, the string that is passed to the custom action contains only one '\'. Not really a problem, you have to check if the path is a UNC path and make sure there are two '\'.
Trailing backslash caused an exception.
This is an interesting problem. As soon as the user enters a path, either absolute path or a UNC path and ended the path with a backslash, the user will get this error when running the setup.

Error 1001: Exception occurred while initializing the installation:
System.IO.FileNotFoundException. Could not load file or assembly:
'file:///C:\WINNT\[Your assembly name here]' or one of its dependencies.
The system could not find the file specified.

This error happens only when the CustomActionData inside double-quotes.

If you check my previous post about passing [TARGETDIR] to custom action, you notice that you have to pass a backslash at the end. You can do the same with a user defined path, something like this /USERDEFINEDDATA="[USERPATH]\". This code works great if the user enters a path with a trailing backslash, and there will be only ONE trailing backslash. The problem is if the user did not supply the trailing backslash, the user will get the same 1001 error again.

My solution is this, set CustomActionData with a character that you know is not a valid path character, for example a Pipe character ('|'). Assign your CustomActionData like this /USERDEFINEDDATA="[USERPATH]|". With this, a user defined path with trailing backslash will come to the custom action as "C:\some Path\some path\|", and user defined path without a trailing backslash will come to the custom action as "C:\Some Path\Some Path|". What you have to do now is to trim the '|' character, and you are good. Now you have a code that can handle user input with or without trailing backslash.

How to Build TFS Build Locally?

HelloWorld — Tue, 11 Mar 2008 12:53:00 GMT

If you need to test your TFS build after playing around with the TFSBuild.proj, you can do that by do the following:

Synchronize the source control to your workspace.
Open Visual Studio 2005 Command Prompt (or Visual Studio 2008 Command Prompt), located under Start>Microsoft Visual Studio 2005>Visual Studio Tools.
Change the directory into your TFSBuild.proj.
Call MSBuild by passing several parameters as follow: MSBuild TFSBuild.proj /p:SolutionRoot=..\..
If you need to test how the build will drop the binaries, pass an extra parameter, for example: MSBuild /p:SolutionRoot=..\.. /p:BinariesRoot=d:\Drop\Binaries\BuildTest

This post was created to help people who search for this information using different keywords, for more detail, MSDN link is here.

How to Make Sure InstallState Files Are Removed After Uninstall?

HelloWorld — Tue, 11 Mar 2008 02:39:17 GMT

If you are building setup using Visual Studio and you have several custom actions and you noticed you see one or more .InstallState files in the target path after uninstall, most likely you have added your custom action to the Install custom action, but nothing else.

What you should do is to add the same custom action to the Uninstall custom action, those InstallState files will be gone.

How to Correctly Pass TARGETDIR to A Custom Action?

HelloWorld — Tue, 11 Mar 2008 02:26:53 GMT

If you have a custom action setup, passing TARGETDIR to the custom action, and suddenly you are experiencing weird error, you may have incorrectly passed the TARGETDIR. Sometimes the Event Viewer have this entry:

The description for Event ID ( 11001 ) in Source ( MsiInstaller ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: Product: Your Product -- Error 1001. Error 1001. Exception occurred while initializing the installation:
System.IO.FileNotFoundException: Could not load file or assembly 'file:///some path' or one of its dependencies. The system cannot find the file specified.., (NULL),

The correct way to pass TARGETDIR is by enclosing it in double-quotes and added a backslash at the end. For example: /param="[TARGET]\". MSDN link here.

Having Fun with VS Setup Project - Database Deployment

HelloWorld — Wed, 30 Jan 2008 21:08:30 GMT

I was given a new task, to create an installer for internal use. I wrote installer before, but it was three years ago, a lot of things have changed.

One of the installer task is to create a sql server db using a script. After much reading, searching, and testing, I got into this msdn article. http://msdn2.microsoft.com/en-us/library/49b92ztk.aspx.

The article was good enough to get me started, the only thing is, the source code was in VB instead of C#. If you decided to follow that example above using C#, there is a chance that you may asked yourself about C# equivalent of VB's My.Settings. Don't worry too much, it just a strong-typed application setting. Just use ConfigurationManager, if you are more comfortable with it.

If you have done database deployment using msi in the past, I will appreciate some feedback or information.

Stay tuned, I am planning to add more stuff that I learned from building setup project using VS 2005.