• Skip to main content

Davton

Outlook development specialists

  • Home
  • About Davton
  • Blog

Blog

How to pass Custom Actions to a WIX Installer using command line arguments

May 1, 2017 by davton

It is often desirable for an installer to be provided with specific data at the time of the installation. For example to supply a user name, password, license string etc. Passing command line arguments while initiating the installation process allows us to do this. This article gives you a detailed description about how to pass data to custom actions in a WIX Installer using command line arguments.

The installation process can be controlled using custom actions. Custom actions can be dynamic linked libraries, Visual Basic scripts or JavaScript files. A custom action written in C# will generate a dynamic linked library file (DLL).

Why use Custom Actions?

The installer provides many standard actions that execute during an installation. However, there may be times where your installation needs expanded functionality. In these cases, custom actions let you extend the capabilities of standard actions. We can use custom actions for the following scenarios.

  • Launch an executable during installation that is installed on the user’s machine or that is being installed with the application.
  • Call special functions during an installation that are defined in a – (DLL).
  • Use functions written in the development languages Microsoft Visual Basic Scripting Edition or Microsoft JScript literal script text during an installation.
  • Defer the execution of some actions until the time when the installation script is being executed.
  • Add time and progress information to a ProgressBar control and a TimeRemaining Text control.

Creating a sample project.

In this sample project, we tell the Wix Installer to use custom actions to execute an .msi with command line arguments. The example will create a sample installer for a Windows Form Application.

Start Visual Studio and go to “File->New Project” under the installed section select Windows Forms Application [Figure1].

Create a new project

Figure 1

Create an Installer for the application

Right click on the solution and “Add->New Project“.  Under Wix Toolset select Setup Project and add a new one. To install Wix Toolset, go to http://wixtoolset.org/releases/ download, setup and install [Figure2].

Add New Project

Figure 2

In the CustomActionSetup project, right-click on the References node and choose Add Reference.

Navigate to the Projects tab, click on the SampleApp project, and click the Add button, and then press OK [Figure3].

Set Reference

Figure 3

Create a Custom Action for the application.

Once we’ve created our setup project, we’ll need to add a C# Custom Action Project to our solution (you can see this project template option in the below screenshot as well).

To create a custom action, right click on the solution and “Add->New Project“. Under Wix Toolset select a “C# Custom Action Project” and add a new one [Figure 4].

 Create Custom Action

Figure 4

Here is the final Solution [Figure 5].

Figure 5

Edit Product.wxs in Wix Setup Project

After creating the setup project you’ll have a Product.wxs file that defines your setup. In the Product.wxs file, we can define custom actions and properties which are sent through the command line.

  • Define two properties “LIC” and “NAME”. See more on the Property Element in Wix here:

http://wixtoolset.org/documentation/manual/v3/xsd/wix/property.html

  • Binary tag a link to the DLL. Here you will need to give a source location for the dll with any unique ID value. When we build the installer, a custom action project (.CA.dll) is created in the bin folder.
  • In the CustomAction tag, you need to define which custom action you are using. In here refer to the “GetArguementValues” custom action and add the Binary Id to the BinaryKey property.
  • After that define the InstallExecuteSequence for a given custom action. Here specify in which step of the installation the custom action should be executed. See more on the InstallExecuteSequence here:

http://wixtoolset.org/documentation/manual/v3/xsd/wix/installexecutesequence.html

The screenshot below shows the location of these elements in the Product.wix file [Figure 6]

Figure 6

Custom Actions

Within the custom action project, you’ll have a new CustomActions class. In the CustomActions class define a method “GetArguementValues” which we have previously added to the “DllEntry” property in the product.wxs file. Here we get a “LIC” and “NAME” property through a Session object. A custom action can interact with an installing package through “Session objects”. The Session object controls the installation process by opening the installer, which contains the installation data. Finally show in a message box with two parameters [Figure 7].

Custom Action Class                                                             Figure 7

Pass Command Line Arguments to Wix Installer

You’ve most likely run .msi files simply by double-clicking them from Windows Explorer. However,you can also run an .msi file by typing the file name at the command line. The advantage of running from the command line is that you can pass parameters to the command.

Open a command prompt and ‘Run as administrator’. Figure [8]. To do this click the start button on Windows and search cmd, right click on command prompt and ‘Run as Administrator.

Run as Administrator

Figure 8

Using command line, we can run the .msi installer and pass parameter values which we define d in the Product.wxs. First go to the location where the  .msi file is saved. For this example it’s located in “C:\pro”. Then, using the command msiexec /i CustomActionSetUp.msi LIC=”xxxxxxxxxx” NAME=”davton”, as shown below, you can run the installer and pass the parameter values [Figure 9].

Command Line

Figure 9

When executing the command, it will open the install wizard and show the message box with the two property values being passed in the command line [Figure 10].

Command Line popup

Figure 10

Summary

This article provides information for creating a custom action in Wix, passing parameters to custom action functions and extracting parameters passed from an installer inside a custom action function.

Written by Tharaka Pathirana  May 2017

Filed Under: Bespoke Development, Outlook Plugin, Technical

Web browser control in .net

November 14, 2014 by chathum

I recently needed to use a webbrowser control with an Outlook plugin – in order to display information hosted in a web application. The big problem is that by default, the .Net browser control emulates Internet Explorer 7. This is a big issue for web developers who want to create nice looking information for the browser control – and use the latest techniques. Regardless of which.net framework I used, the browser control was emulating IE 7 (seriously ?) So the poor web developers working with me had a hard time trying to support IE7.

I discovered you can force (emulate) a preferred Internet Explorer version using a simple registry mod. You can check this MSDN article for more information on how to do this. The best thing to notice is you don’t need admin rights for this.

HKEY_LOCAL_MACHINE (or HKEY_CURRENT_USER)
   SOFTWARE
      Microsoft
         Internet Explorer
            Main
               FeatureControl
                  FEATURE_BROWSER_EMULATION
                     yourapp.exe = (DWORD) 00009000

Since my code is required to run as an outlook plugin, the application runs inside outlook.  So I can’t use yourapp.exe, I always have to use outlook.exe if I want this done inside an outlook plugin. I started writing some code to do the this registry mod.
Microsoft.Win32.Registry.SetValue(@"HKEY_CURRENT_USERSoftwareMicrosoftInternet ExplorerMainFeatureControlFEATURE_BROWSER_EMULATION", appName, ieVer)
You can find the IE version by using this table  

Value Description
11001 (0x2AF9 Internet Explorer 11. Webpages are displayed in IE11 edge mode, regardless of the !DOCTYPE directive.
11000 (0x2AF8) IE11. Webpages containing standards-based !DOCTYPE directives are displayed in IE11 edge mode. Default value for IE11.
10001 (0x2711) Internet Explorer 10. Webpages are displayed in IE10 Standards mode, regardless of the !DOCTYPE directive.
10000 (0x02710) Internet Explorer 10. Webpages containing standards-based !DOCTYPE directives are displayed in IE10 Standards mode. Default value for Internet Explorer 10.
9999 (0x270F) Windows Internet Explorer 9. Webpages are displayed in IE9 Standards mode, regardless of the !DOCTYPE directive.
9000 (0x2328) Internet Explorer 9. Webpages containing standards-based !DOCTYPE directives are displayed in IE9 mode. Default value for Internet Explorer 9.Important  In Internet Explorer 10, Webpages containing standards-based !DOCTYPE directives are displayed in IE10 Standards mode.
8888 (0x22B8) Webpages are displayed in IE8 Standards mode, regardless of the !DOCTYPE directive.
8000 (0x1F40) Webpages containing standards-based !DOCTYPE directives are displayed in IE8 mode. Default value for Internet Explorer 8Important  In Internet Explorer 10, Webpages containing standards-based !DOCTYPE directives are displayed in IE10 Standards mode.
7000 (0x1B58) Webpages containing standards-based !DOCTYPE directives are displayed in IE7 Standards mode. Default value for applications hosting the WebBrowser Control.

I initially ran this code inside my outlook plugin but it didn’t give me what I actually want. When Outlook loads for the first time it checks the registry for this value and decides whether to use IE7 or not. So, doing the modification inside the application will only affect the version used once the application has restarted. I solved the problem by writing a custom action in the installer.
When researching this solution I came across this awesome website which tells you the current browser version. Of course you can write your own script to find this out.

Filed Under: Technical

  • « Previous Page
  • Page 1
  • Page 2
  • Page 3

Copyright © 2025 · Davton Limited

  • Home
  • About Davton
  • Blog
  • Privacy Policy