Replacing VDPROJ Setup files with InstallShield/WIX

Question

Our product currently installs via 4-5 MSI's which are created from .vdproj files which consist are created from the output from vs 2010 projects and additional information in merge modules.

I have been looking at InstallShield and WIX as a possible replacement due to VS2012 no longer supporting VS Setup Projects (oh no!) so we have to find something else.

I've had a little play with InstallShield and I couldn't really get to grips with it, additional to installing the product, the installer also has to take in a few parameters such as a database name and location etc. I couldn't seem to find a way to get this info into the InstallShield project - This was using InstallSHield limited edition for visual studio though

I'm not sure which would be the best to use? Has anybody had experiences with converting to WIX or IS from a VDPROJ?

EDIT It looks like WIX is going to be the easiest and I am trying to get to grips with it. I cant seem to find any useful posts that allow me to direct project output into my WIX installer, and how to create variables. (Without using plugins)

Answer 1

It's hard to give a simple answer because you are actually asking really high level questions that require an understanding of your installation needs and a whole bunch of training in the art of creating installers.

Personally I have installers that are 100% WiX, 100% InstallShield ( Both Limited Edition and Premiere Edition ) and a blend of the two.

Limited Edition is limited but it also does some things really well and provides some features that aren't really there and/or easy to implment in WiX.

One good strategy is to use InstallShield LE as a simple container and then do most of your authoring in WiX. I describe that pattern here in my blog:

Augmenting InstallShield using Windows Installer XML - Certificates

InstallShield Professional and above has a tool for migrating VDPROJ projects but I'd use it with caution. Most VDPROJ installers have some horrible authoring and it would be better to refactor rather then migrate.

Answer 2

I strongly suggest looking at Wix#. See http://www.codeproject.com/Articles/31407/Wix-WixSharp-managed-interface-for-WiX.
Also see the CodePlex home page: http://wixsharp.codeplex.com/

For developers primarily coding in C#, Wix# this would probably be the most simple and comfortable skill set to add, and it is free and directly integrates into the Visual Studio environment. I've been using it with great success in Visual Studio 2012 and 2013.

For C# developers needing to create a Windows Installer MSI to deploy their app, Wix# is perhaps the best replacement for the "Packaging and Deployment" project type that Microsoft removed from Visual Studio starting with VS2012. Wix is a C# front end for the WiX (Windows Installer Xml) Toolset. Using Wix# allows building a complete Windows Installer MSI in the C# language.

Wix# is useful for a broad range of installation/deployment scenarios, and lends itself reasonably well to Continuous Integration scenarios. There are Wix# examples for deploying Windows desktop applications, for installing Windows Services, and installing ASP.NET websites, and many more types of installations.

Wix# handles typical installer requirements, and the Wix# installer code for simple projects is indeed simple. For application installs that are more complex, and require advanced features, Wix# can tap into the power of the full WiX Toolset when needed. For example, when installing a .NET application, a typical requirement would be to install the application exe and dll files, and tailor some .NET configuration files and/or registry entries on the target system.

Below is an example of the C# code for a simple Wix# installer that installs an application on a target system, and modifies some configuration files. This example assumes that you have written a utility named "TailorMyConfig.exe", e.g., a simple C# program that uses ConfigurationManager.AppSettings routines, and you are deploying this exe along with your app.

using System;
using System.Windows.Forms;
using System.Diagnostics;
using Microsoft.Deployment.WindowsInstaller;
using WixSharp;

class Script
{
    static public void Main(string[] args)
    {
        var project = new Project("MyProduct",
                          new Dir(@"%ProgramFiles%\My Company\My Product",
                              new File(@"Files\Bin\MyApp.exe"),
                              new File(@"Files\Bin\TailorMyConfig.exe")),
                          new ManagedAction("UpdateConfigFile"));

        project.Id = new Guid("6f330b47-2577-43ad-9095-1861ba25889b");

        Compiler.BuildMsi(project);
    }
}

public class MyCustomAction
{
    [CustomAction]
    public static ActionResult UpdateConfigFile(Session session)
    {
        if (DialogResult.Yes == MessageBox.Show("Config file update ready to run.\n Update config file(s) now?", 
                                                "Config Tailoring Utility",
                                                MessageBoxButtons.YesNo))
        {
            Process.Start("TailorMyConfig.exe", "Run utility to tailor config file to current system");
        }
        return ActionResult.Success;
    }
}

Note that there are "better" ways to modify a config file using WiX XML features. For simplicity, the example above assumed a custom-written C# exe utility for modifying config files. I would suggest using WiX XML capabilities for doing this instead. You can incorporate nearly any WiX XML capabilities directly into your Wix# setup using the Wix# technique of "XML injection".

Remember, Wix# is simply a C# front end that emits WiX XML syntax. After Wix# has emitted the WiX XML (wxs file), that wxs file can easily be post-processed to insert additional WiX XML features. Then the resulting wxs file gets compiled by the WiX Toolset into an MSI.

For an example of using XML Injection to incorporate WiX XML features into a Wix# (C#)installation, look here In Wix#, how to avoid creating a physical folder on the target system, when deploying only registry entries? In that question, see my answer that uses the technique of hooking up a delegate to the "WixSourceGenerated" event.

You could then use this XML injection approach to insert some WiX XML into your installer that would accomplish the config file editing. An example of some typical WiX XML to modify config files is here: How to modify .NET config files during installation?

Another typical requirement of an installer would be to add or modify Windows Registry entries on a target system. Wix# provides direct support for that using the "RegValue" class. The advantage there is when using Wix# you also get a full "uninstall" capability for free, including uninstalling/reverting registry entries to the pre-install state. This is a natural result of Wix# being built on top of the WiX Toolset and Windows Installer technology. An example of a registry-only Wix# installer is here: In Wix#, how to avoid creating a physical folder on the target system, when deploying only registry entries?

The Wix# approach has been very useful in my environment, and it allows use of the familiar C# skillset without having to jump headfirst into the full complexity of the WiX XML installer technology.

The first accepted answer advocated this approach:

One good strategy is to use InstallShield LE as a simple container and then do most of your authoring in WiX. I describe that pattern here in my blog: http://blog.iswix.com/2011/01/augmenting-installshield-using-windows_19.html

While that is a fine and workable approach, the approach I'm suggesting here has the following advantages:

ADVANTAGES OF USING Wix# PLUS WiX APPROACH

• No need whatsoever to deal with InstallShield LE or any other proprietary installer product
• The entirety of most installers are written in C# code, a familiar skill set
• No need to learn the full WiX toolset environment up-front; you can start with C# code and then add the advanced WiX capabilities as you need them, using XML Injection.
• The approach would work well in Continuous Integration environments, with all the components lending themselves to being XCopy-deploy installed on build servers, and all components being eminently suitable for automation by scripting, e.g., Powershell scripts.
• If Microsoft changes course AGAIN on installer tools bundled with Visual Studio, you will NOT be impacted.

ELEMENTS IN COMMON WITH IS LE + WIX

• Built on top of WiX Toolset capabilities, thus all capabilities of WiX XML can be incorporated into an installer
• Many excellent "how-to's" for WiX solutions to deployment problems are available on SO and elsewhere
• Generates authentic MSI Windows Installers, complete with uninstall capabilities and all the great features of that technology.
• You will want to learn more about WiX and Windows Installer technology when creating installers. Advanced capabilities will often require dropping down into WiX XML.
• Both are integrated more or less seamlessly into the Visual Studio environment. (If anything, the Wix# approach would have a slight advantage)

So, while the other approach is a workable solution, I recommend Wix# + WiX Toolset as the path of least aggravation, going forward, for VS2012, VS2013, VS201x. Perhaps the biggest advantage is that you are unlikely to ever have to have to change your underlying deployment technology and approach again, to be blindsided by Microsoft again, no matter what no matter what backroom deals Microsoft's marketing managers make to include or pull deployment technology from Visual Studio.

Answer 3

For a free tool WiX is your best choice. If you also are interested in commercial tools, Advanced Installer can help you create/convert the project much faster, without any scripting required. It also has a predefined project template for importing your VDPROJ. For what you need an Enterprise license is required, as you need access to its Dialogs Editor and SQL Scripts features. But you can test all of them in the trial period.

Answer 4

If you want to move to other installation system - NSIS or Inno Setup try this Visual Studio extension: http://visualstudiogallery.msdn.microsoft.com/5e57fe9a-ae5d-4740-a1c3-7a8e278e105b