Question

I've seen many questions like this one asked all over the place but I've found none with my particular twist on it that has been answered. I'm using purely wix to build minor upgrades.

This question is an example which is muchlike my scenario, except for the last part.

  • I have a product for which I build an RTM msi file, let's call it Product-1.0.msi
    • Contains A.dll
  • I then build a patch called Product-1.0.1.msp which uses Product-1.0 as it's baseline
    • Adds B.dll
  • I then build a patch called Product-1.0.2.msp which also uses Product-1.0 as it's baseline
    • Adds B.dll + C.dll

This means that my patches will always contain the preceding fixes and supersede each other.

Scenarios:

  • 1.0 -> 1.0.1 Works fine
  • 1.0 -> 1.0.2 Works fine
  • 1.0 -> 1.0.1 -> 1.0.2 Doesn't work

In the last scenario, the msp runs without complaint but very quickly. The reason is obvious afterwards, because nothing is actually done. In ARP, the patch is listed with version 1.0.2 under Installed Updates, but the target product isn't updated, files that were added to the patch (C.dll) aren't added to the install folder. Same goes for updates, files aren't modified by the second patch.

When uninstalling 1.0.2, files that were included in the patch (C.dll) are removed however, including those that were installed already with 1.0.1 (B.dll).

ProductCode is unchanged.
UpgradeCode is unchanged.

Here's the Patch.wxs contents:

<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
    <Patch  MinorUpdateTargetRTM="yes"
            AllowRemoval="yes"
            Manufacturer="{Manufacturer}"
            DisplayName="{ProductName} {Version} Patch"
            Description="{ProductName} {Version} Patch"
            Classification="Update" 
            TargetProductName="{ProductName}" >
        <Media Id="5000" Cabinet="Patch.cab" EmbedCab="yes">
            <PatchBaseline Id="RTM">
                <Validate ProductVersionOperator="LesserOrEqual" ProductId="yes" UpgradeCode="yes" ProductVersion="Update" />
            </PatchBaseline>
        </Media>
        <PatchFamilyRef Id="PatchFamily"/>
    </Patch>

    <Fragment>
        <PatchFamily Id='PatchFamily' Version='{Version}' Supersede='yes'>
        </PatchFamily>
    </Fragment>
</Wix>

In this snippet, {Version} is 1.0.1 in the first patch and 1.0.2 in the second. Otherwise, they're identical.

Any thoughts on this?

Was it helpful?

Solution

I finally got it working, and here's what I found. First of all, enable MSI logging.
I found two problems that both resulted in the same behavior.

The first clues I found were these two snippets from the MSI logs:

1.0.1 install:

MSI (s) (A4:60) [09:42:30:917]: SELMGR: New components have been added to feature 'ProductFeature'
MSI (s) (A4:60) [09:42:30:918]: SELMGR: Component 'comp_F8F80909F3D340B19A4CF3E6E172F386' is a new component added to feature 'ProductFeature'
....
MSI (s) (A4:60) [09:42:33:077]: Executing op: ComponentRegister(ComponentId={B49318A5-8DDE-449F-9B77-B67A3F7F8952},KeyPath=C:\[...]\B.dll,State=3,,Disk=1,SharedDllRefCount=0,BinaryType=0)

This is the new file (B.dll) added in the patch.

1.0.2 install:

MSI (s) (A4:70) [09:47:02:508]: SELMGR: ComponentId '{B49318A5-8DDE-449F-9B77-B67A3F7F8952}' is registered to feature 'ProductFeature', but is not present in the Component table.  Removal of components from a feature is not supported!
MSI (s) (A4:70) [09:47:02:508]: SELMGR: Removal of a component from a feature is not supported

The reason for this, I'm afraid, is simple and slightly embarrasing. B.dll had been tagged with a new component Id. For some reason, the installer (running the msi/msp directly) didn't say anything about the error and simply gave up but left the application registered as if it were in its upgraded state (1.0.2 in ARP).

So my tip to you here is: Diff your generated fragments and make sure that any new files from the baseline appear with the same component and file ids in both patch .wxs files! Even when you already think you know they do.

The second problem was that I wanted to bundle .Net using the WixNetfxExtension:

Problem was that I was trying the install on a disconnected system and had put the redist installer in the bundle rather than in a 'redist' subfolder of the bundle exectuable. Again, the installer just gave up and left the application in its (falsely) upgraded state, even if .Net was already installed. This really shouldn't happen, especially since .Net is a prereq, so I might have done something else to the bundle that prevented it from acting the way it should upon the error.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top