Tag Archives: wix

Programming

What Causes Error 1154 in WiX

Credit: www.joyofsetup.com

Recently, as I was working on one of our installers, I had a very strange issue crop up. This particular installer is fairly complicated, but also fairly stable.  It has many managed custom actions, and I was merely adding some functionality to it. I was testing the installer and ran into an 1154 error:

“There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run.“

That’s fine. This happens. It’s pretty common, actually.

  • Check the names in the custom action declaration.  Do they match the DLL and method name, including case?
  • Are you trying to run a 64bit DLL using a 32bit installer?
  • Are you running MakeSfxCA.exe correctly with the most recent version of the DLL and installer?
  • Does the method you’re trying to call have the correct signature?

[CustomAction]Public static ActionResult MyCustomAction(Session session){….}

In this case, my problem action was, let’s say, HereIsMyCA. I checked through all of the above items several times. Most confusing was that other custom actions from the same DLL worked just fine. One might say I was getting a bit frustrated.  Eventually, I changed the name of the action and method – ThisIsAwfulPleaseWork.

…and it did.

After some experimentation I discovered that the problem lay in the capitalization of the C# method.  HereIsMyCA was breaking, but HereIsMyCa was fine. Most other methods with similar capitalization (several capitals in a row) worked fine. I’ve had one other method break. There is no rhyme or reason to it, but I hope that I save someone some hours with my discovery.

IT, Programming

Major Upgrades using WiX

Major Upgrades using WiX

Recently one of my colleagues wrote about his experience with WiX, and how he could create a simple installer in fifteen minutes. Today I want to talk about taking your newfound WiX installer to the next level by configuring your WiX installer to perform major upgrades.  In most cases a major upgrade means removing any previous version of an application and installing the new version.

Depending on which version of WiX you are using, you have a couple of options to perform a major upgrade.

Special Considerations:

Special considerations should be made before you start creating your installer. One of the most important ones in my opinion is deciding if your installer will be per-user or per-machine. By default WiX is a per-user install.  If you want your installer to be per machine you can add the following your solution:

<!-- Install at a per-machine level and not per-user -->
<Property Id="ALLUSERS" Value="1"/>

Any upgrade that you make should use a consistent ALLUSERS property. If you decided to change this once your application is already deployed, a major upgrade will not be looking in the same place, and any new version of the installer will not be able to detect the old installed version. This can lead to multiple versions of the software installed on one system.

WiX 3.5.1315.0 and later

In version 3.5.1315.0 of WiX the Major Upgrade Element was introduced, which makes common upgrade scenarios very simple.

It can be as simple as:

<MajorUpgrade AllowDowngrades="no" DowngradeErrorMessage="A newer version of this application is already installed."/>

If you try to run the installer on a system that already has a newer version you will receive an error with the DowngradeErrorMessage such as:

However if you are indeed installing a new version, then the installer will automatically uninstall the old version and install the new version. How easy is that?!

Pre WiX 3.5.1315.0

If you are using a version of WiX before 3.5.1315.0 then you have to perform a major upgrade in a slightly more complicated way. Seeing as everyone may not be using the newer version of WiX, I think it is still worth explaining.  Note: What defines a Major upgrade is changing the Product Version and Changing the Product ID; just changing the product version will be considered a minor upgrade.

Step  1   Define your GUIDS:

Whenever you are ready to perform a major upgrade you will need to change your product’s GUID. The product GUID is how WiX determines major versions of the product. In my case I am using *, which will generate a new unique GUID every time I build my installer.

  <!-- * means WIX will generate a new GUID -->
	<Product Id="*" Name="$(var.Product.Name)" Language="$(var.Product.Lang)" Version="$(var.Product.Version)" Manufacturer="$(var.Product.Manufacturer)" UpgradeCode="f47c5510-7e95-11e1-8027-bbc14824019b">
		<Package InstallerVersion="$(var.Package.InstallerVersion)" Compressed="yes" Platform="$(var.Platform)" />

Step 2 Define your condition message:

<Condition Message="A newer version of this application is already installed.">
      <![CDATA[Installed OR NOT NEWER_VERSION_FOUND]]>
    </Condition>

Step 3 Define upgrade table:

The upgrade table tells the installer what the versions it should detect are and how to respond. You will notice that when I detect newer versions, OnlyDetect = “true” because I do not want to replace newer versions of my product.

<!-- Upgrade Table -->
    <Upgrade Id="f47c5510-7e95-11e1-8027-bbc14824019b">
      <UpgradeVersion
        Property="OLD_VERSION_FOUND"
        Minimum="1.0.0.0"
        Maximum="$(var.Product.Version)"
        IncludeMinimum="yes"
        IncludeMaximum="no"
        OnlyDetect="no"
        IgnoreRemoveFailure="yes"
        MigrateFeatures="yes"
        Language="1033"  />

      <UpgradeVersion
        Property="NEWER_VERSION_FOUND"
        Minimum="$(var.Product.Version)"
        IncludeMinimum="no"
        OnlyDetect="yes"
        Language="1033"  />
    </Upgrade>

Step 4 define the Install Execute Sequence

    <!--Removes the old version and then installs the new version-->
    <InstallExecuteSequence>
      <RemoveExistingProducts After="InstallInitialize"></RemoveExistingProducts>
      <InstallExecute After="RemoveExistingProducts"></InstallExecute>
    </InstallExecuteSequence>

And that’s it. I hope this helps others who are looking to perform major upgrades with their WiX installers. If you are working a lot with WiX, I recommend you check out the book WiX: A Developer’s Guide to Windows Installer XML  by  Nick Ramirez

OfficeWriter

Creating and Hooking Up a Custom Action in WiX

As mentioned previously, we started using WiX for our own installers. Out of the box, WiX can do pretty much anything you’d like, but sometimes you need to do a little something extra. One avenue we can use is a Custom Action (CA). There are quite a few types, but among the most useful is the Type 1 Custom Action. This style of action is a function call to an external Custom Action Dynamic Link Library.

These types of custom actions can call code from basically anywhere, so they can utilize existing code for things like validating a license key, or determining other requirements. In this tutorial I’ll show you everything you need to create a Type 1 Immediate Custom Action and link it into the installer.

Part 1: Creating and Hooking Up a Custom Action DLL

With Votive, setting up a DLL to be a Custom Action DLL is as easy as setting up a new project. Continue reading Creating and Hooking Up a Custom Action in WiX →

Programming

Don’t Pay for Install Tools when WiX Works

Recently we found it beneficial to rewrite one of our Windows installers. The previous one was built with the well-known InstallShield 2008, which is a pretty powerful GUI tool built over a very basic language called InstallScript. You can do pretty much anything you need with the tool, but a lot of it can be rather arcane and not at all straightforward. This is fine and dandy if a team has a dedicated installer engineer, but when the installer is rarely touched it doesn’t tend to work out as well. InstallScript itself eventually runs into using goto statements, something abhorrent to many of us. On top of that, the tool is a few grand per license. We needed to make some major changes to our installer, and knowing the state of the tool and code for the existing one we thought it better to seek out alternatives.

Why WiX? WiX actually comes out of Microsoft, and was amongst the first of their projects to be delivered open source under the Common Public License. Since it’s open source, it’s also free. Before, we had to log into the one machine that can actually make changes to the installer, as we only had the one license. Now, every developer can just have WiX installed on their box outright. Additionally, WiX comes with Votive, a Visual Studio plugin. As we’re already using Visual Studio to develop OfficeWriter, the project in question, this is simply a nice feature we get for free. One doesn’t need Visual Studio or the plugin to develop a WiX installer, however. Continue reading Don’t Pay for Install Tools when WiX Works →