Blog Archives

C# Create a Windows Installer Class Custom Action bootstrap DLL in .Net

The standard windows installer project included with Visual Studio right out of the box is great in many deployment scenarios.

For more advanced needs, organizations and developers usually defer to 3rd party solutions, such as InstallShield, Wise, wix or NSIS (NullSoft).

These solutions are all very well tested and have minimal learning curve in a lot of cases. However, if you are tight on budget or simply looking for the experience and full customization, you can also create your own custom action installer class in Visual Studio.

Simply create a new DLL project included in the same solution as your windows installer project. From the Windows Installer Project go to “File System” and in your Application Folder add “Project Output” and select your new DLL. Now go to the “custom actions” tab and under install and/or uninstall right click and “Add Custom Action” then select the output under Application Folder. That’s it!

Make sure the class for your DLL has “RunInstaller” attributes and looks similar to the snippet below. You may also want to do some light reading on the “CustomActionData” property to see if there are any variables you may need such as “ProductCode”.

To change the custom action data property, from the custom action tab simply select your DLL output after adding it, and expand the Visual Studio Properties tab on the side.

using System;
using System.Collections;
using System.Collections.Generic;
using System.ComponentModel;
using System.Configuration.Install;
using System.Diagnostics;
using System.IO;
using System.Reflection;
using System.Runtime.InteropServices;

namespace MSIBootstrap
{
    [RunInstaller(true)]
    public partial class InstallHelper : Installer
    {
        public static string InstallTitle = "Discount Notes"; //used by install/uninstall to get window handle
        
        public InstallHelper()
        {
            InitializeComponent();
        }

        public override void Install(System.Collections.IDictionary stateSaver)
        {
try {
//your custom code
base.Install(stateSaver);
}
catch (Exception ex) {
throw new InstallException(ex.ToString());
}
}

 public override void Uninstall(System.Collections.IDictionary stateSaver)
        {
//mimic same try/catch design pattern if you like
base.Uninstall;
}
}

With this approach, you are essentially using the standard windows installer project to bootstrap your custom action DLL.

This is very powerful, and allows you to define your own code logic and conditions as well as custom interfaces and forms designed directly from within Visual Studio.

References
InstallShield, http://www.flexerasoftware.com/products/installshield.htm
Wise installer, http://www.wise.com/Products/Installations/WiseInstallerEvaluations.aspx
wix installer, http://wix.sourceforge.net/
Nullsoft NSIS, http://nsis.sourceforge.net/Download
Wikipedia (bootstrapping), http://en.wikipedia.org/wiki/Bootstrapping_%28computing%29
devx.com, http://www.devx.com/dotnet/Article/20849/1954
PCReview.co.uk, http://www.pcreview.co.uk/forums/install-project-custom-action-failure-t2612207.html
codefounders.com (persisting savedState), http://www.codefounders.com/community/blogs/davidg/archive/2007/06/27/persisting-state-in-a-windows-installer-managed-custom-action.aspx
MSDN, “CustomActionData”, http://msdn.microsoft.com/en-us/library/2w2fhwzz(v=vs.80).aspx

Advertisement

Call Cancel from Custom Action in .Net Windows Installer Project

As an alternative to using the “Rollback” or “InstallException” approach, simply use pinvoke/interop to call the cancel button on the base installer form directly.

(see my related post for more detail and full code)

ShowWindow(msiwindowhandle, ShowWindowCommands.Show);
                IntPtr cancelbuttonhandle;
                const int BM_CLICK = 0x00F5;
                msiwindowhandle = FindWindow("#32770", InstallTitle);
                cancelbuttonhandle = FindWindowEx(msiwindowhandle, IntPtr.Zero, "Button", "Cancel");
                SetActiveWindow(msiwindowhandle); //necessary for button click to fire
                SendMessage(cancelbuttonhandle, BM_CLICK, IntPtr.Zero, IntPtr.Zero);

References
https://ronniediaz.com/2011/06/20/the-savedstate-dictionary-does-not-contain-the-expected-values-and-might-have-been-corrupted/

the savedstate dictionary does not contain the expected values and might have been corrupted

This is a common error with custom action development, especially if you are working with your own custom installer class, not using wix or some other windows installer derivative.

Since many of the Google entries for this were unresolved, thought I would give it a quick tackle. 😉

First Solution

Throw an exception.

This solution seems to be the most popular among Google results.. You can throw a new Exception or InstallException, but this creates an unsightly error message which you would not want your users to see.

 public override void Install(System.Collections.IDictionary stateSaver)
        {
            Process proc = new Process();
            string path = Path.GetDirectoryName(System.Reflection.Assembly.GetAssembly(typeof(InstallHelper)).Location);
            proc.StartInfo.FileName = path + "\\somesubprocess.exe";
            
//note ProductCode argument is an installer variable
            proc.StartInfo.Arguments = "\"" + this.Context.Parameters["action"] + "\" \"" + this.Context.Parameters["ProductCode"] + "\" \"" + this.Context.Parameters["src"];

            proc.Start();

//optional showwindow code to force window into foreground
 IntPtr msiwindowhandle;
            msiwindowhandle = FindWindow("#32770", InstallTitle);
            ShowWindow(msiwindowhandle, 0);

if (proc.ExitCode == 1)
            {
throw new InstallException("Installation cancelled. Any changes made will now rollback.");
                Process.GetCurrentProcess().Kill();
                if (stateSaver == null)
                {
                    stateSaver = new Dictionary<string, string>();
                    //Add some default values to the dictionary here...if you dare..
                }

                base.Uninstall(stateSaver);
                base.Rollback(stateSaver); //will give you article title error
            }
            else
            {
                base.Install(stateSaver);
            }
}

The code above was a bit much to simply explain the concept of throwing a new “InstallException”, but does illustrate there are definitely things you can do from your custom action bootstrap DLL which have room for error (like spawning a sub process!).

The Alternative

…is to simply click/call the cancel button for the base installer from your custom action code.

Since the msi installer process is separate from your bootstrap custom action DLL, you will have to use some old school tricks to work around the constraints.

Simply import User32.dll and call the “SendMessage” function, passing in the handle of cancel button. See code example below:

using System.Runtime.InteropServices;

[DllImport("User32.dll", EntryPoint = "SendMessage")]
        public static extern int SendMessage(IntPtr hWnd, int Msg, IntPtr wParam, IntPtr lParam);

        [DllImport("user32.dll", SetLastError = true)]
        private static extern IntPtr FindWindowEx(IntPtr parentHandle, IntPtr childAfter, string className, string windowTitle);

        [DllImport("user32.dll", SetLastError = true)]
        public static extern IntPtr SetActiveWindow(IntPtr hWnd);

        [DllImport("user32.dll", SetLastError = true)]
        static extern IntPtr FindWindow(string lpClassName, string lpWindowName);

        [DllImport("user32.dll")]
        static extern bool ShowWindow(IntPtr hWnd, ShowWindowCommands nCmdShow);

        enum ShowWindowCommands : int
        {

            Hide = 0,
            Normal = 1,
            ShowMinimized = 2,
            Maximize = 3,   
            ShowMaximized = 3,
            ShowNoActivate = 4,
            Show = 5,
            Minimize = 6,
            ShowMinNoActive = 7,
            ShowNA = 8,
            Restore = 9,
            ShowDefault = 10,
            ForceMinimize = 11
        }

public static string InstallTitle = "AppbarTitle"; //used to get the window handle

  public override void Install(System.Collections.IDictionary stateSaver)
        {
ShowWindow(msiwindowhandle, ShowWindowCommands.Show);
                IntPtr cancelbuttonhandle;
                const int BM_CLICK = 0x00F5;
                msiwindowhandle = FindWindow("#32770", InstallTitle);
                cancelbuttonhandle = FindWindowEx(msiwindowhandle, IntPtr.Zero, "Button", "Cancel");
                SetActiveWindow(msiwindowhandle); //necessary for button click to fire
                SendMessage(cancelbuttonhandle, BM_CLICK, IntPtr.Zero, IntPtr.Zero);
}

The MSDN Social article listed in my references below comes up in Google rankings high for the error the OP received when calling the Rollback method manually. To track any social momentum my solution may possibly gain, refer to this link.

References
MSDN Social, http://social.msdn.microsoft.com/Forums/en/winformssetup/thread/ea7d09d1-2812-4f04-b6ed-e7293f2a2d75
wix, http://wix.sourceforge.net/
MSDN, “Installer.Rollback Method”, http://msdn.microsoft.com/en-us/library/system.configuration.install.installer.rollback.aspx
MSDN, “Installer.BeforeRollback Method”, http://207.46.16.248/en-us/library/system.configuration.install.installer.beforerollback%28VS.80%29.aspx

Create an Uninstall Shortcut for Windows Installer in C#

When utilizing the windows installer project type bundled with Visual Studio I was very surprised to find there was no simple functionality to add an uninstall shortcut.

Instead, there are a few workarounds, some better than others but overall going to have to get your hands dirty to make this one work.

Option 1 – Batch File

Create an uninstall batch file and add a shortcut which points to the batch.

Only downside of this solution, which is actually the simplest, is an ugly little bugger we all know as the DOS window pops up when you execute the batch.

(courtesy of tech.chitgoks.com)

@echo off
msiexec /x {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}

Option 2 – VBS File

No code example for this option since I didn’t even consider trying this one personally, but this would be to create the equivalent of the code above using WshShell in vbscript (which is actually a similar end result as the code in option 3).

The .vbs file would execute cleanly without a DOS prompt, but my experience with .vbs files has found that they are not AntiVirus friendly and don’t always port OS’es cleanly either. Certain API calls slightly change over time and can break syntax, and you never know if John Doe’s newest antivirus update will flag your .vbs file and prevent it from executing.

Option 3 – Roll up those sleeves

Create a separate app which calls msiexec either by instantiating a hidden cmd.exe process window, or calling it directly also using process object. Then add this separate app to your deployment project solution and create a shortcut in the installer which points to the primary output of your separate app project.

Using this method is the most work, but the best end result for the consumer IMO (isn’t that usually how it works? :P). If you wanted, you could even create your own uninstall process and run msiexec in “unattended” a.k.a “silent” mode and uninstall your app quietly in the background.

(courtesy of endofstream.com)

using System.Diagnostics; //namespace containing process RD

public partial class App : Application
{
  void Application_Startup(object sender,StartupEventArgs e)
  {
    for(int i = 0;i != e.Args.Length;++i)
    {
      if(e.Args[i].Split('=')[0].ToLower() == "/u")
      {
        string guid = e.Args[i].Split('=')[1];
        string path = Environment.GetFolderPath(Environment.SpecialFolder.System);
        ProcessStartInfo uninstallProcess = new ProcessStartInfo(path+"\\msiexec.exe","/x "+guid);
        Process.Start(uninstallProcess);
        System.Windows.Application.Current.Shutdown();
      }
    }
  }
}

Keep in mind in all of these scenarios, the application guid is necessary to pass as a parameter to msiexec. To pass this variable you will need to specify the productcode as a parameter in custom action data.

Such as:

CustomActionData => /productcode = [ProductCode]

I believe [ProductCode] may also be case sensitive, as I had originally specified “PRODUCTCODE” in one of my installers but this did not seem to pass through..

However…

If you’re still reading by this far (and yes I tried to blow up however to draw your eyes), keep in mind your uninstall executable or batch is calling msiexec, not the other way around, so “ProductCode” is not yet part of the mix.

I’ve yet to find the cleanest solution to this final issue, but overall my thoughts would be to pass product code through to a different separate application added to your deployment project solution as part of the install process, and have this application either store the product code in a generic location such as:

Environment.SpecialFolders.ApplicationData

…or, still using your “install helper” application, store it somewhere in the application directory in program files created by the installer. Essentially the same thing as application data, just leaves less chance of any traces of your program being left behind on uninstall.

Enjoy. 😉

References
http://tech.chitgoks.com/2009/02/06/visual-studio-create-an-uninstaller-shortcut-in-your-installer-wizard/
http://endofstream.com/creating-uninstaller-in-a-visual-studio-project/
Windows Installer (Relevant links for Custom Actions), http://msdn.microsoft.com/en-us/library/aa368066(v=vs.85).aspx, http://msdn.microsoft.com/en-us/library/2w2fhwzz%28v=vs.71%29.aspx, http://msdn.microsoft.com/en-us/library/2w2fhwzz%28v=vs.80%29.aspx, http://msdn.microsoft.com/en-us/library/aa368066%28v=VS.85%29.aspx, http://msdn.microsoft.com/en-us/library/aa367457%28VS.85%29.aspx
MSIexec command line options, http://msdn.microsoft.com/en-us/library/aa372024%28v=vs.85%29.aspx
Flexera Software, http://community.flexerasoftware.com/archive/index.php?t-128559.html