WiX UI Not Updating As Expected

During my recent forays into the world of WiX I’ve been slowly hacking away at the steep learning curve. This really is a huge framework that is dealing with an intrisically complicated process. For my own projects I’ve always stuck with Inno Setup and to be honest I don’t have any compelling reason to move them away from Inno at the moment as they are functioning as expected.

Anyway, the last problem I’ve encountered that took a question to the WiX mailing list to answer was regarding showing messages conditionally in the UI based on custom property values changing.  What was confusing was that the log file showed all the custom actions and properties being correctly processed but the UI never actually updated.  Sound familiar?  If you’r having this problem, simply try hitting the back or next button and then go back to the dialog that should have updated?  I bet you now see the updated value in the UI (provided all your WiX source is correct of course!).

This issue is that dialogs are never redrawn.  This is actually a limitation in the MSI UI implementation.  Whilst I haven’t looked into alternatives like replacing the MSI UI (lots of work apparently) there is a hacky solution to this.  Making twin dialogs … basically you create an exact copy of the dialog that should be updated and then once the property changes you simply show this twin dialog and it will appear as though the UI has updated when in fact it’s showing an entirely new dialog.

In the snippet below you can see that the last published event is the call to the current dialogs twin. You will need to give the twin dialog a new Id but all the others can remain the same. Not a nice solution as you now have two dialogs to maintain with any changes but it is a solution none-the-less.

<Control Id="TestDbConnection" Type="PushButton" Width="100" Height="17" X="19" Y="202" Text="Test Connection" TabSkip="no">
    <Publish Event="DoAction" Value="SetGeneratedConnectionString">1</Publish>
    <Publish Event="DoAction" Value="CheckDataAccessCa">1</Publish>
    <Publish Event="NewDialog" Value="DatabaseConfigTwinDlg">1</Publish>

Managed Custom Actions Failing in WiX?

Well after many hours wondering why my WiX custom actions were failing to run I made an interesting discovery.  The library that I had created to hold my custom actions was all being referenced correct from the main WiX project code in a separate WiX fragment, like this:

	<Fragment Id="CheckDatabaseAccessCa">
    <CustomAction Id="CheckDataAccessCa" BinaryKey="ProjectName.dll" DllEntry="CheckDatabaseConnection" Execute="immediate" Return="check" />
    <Binary Id="ProjectName.dll" SourceFile="$(var.ProjectName.TargetDir)$(var.ProjectName.TargetName).CA.dll"/>

Changing any part of this made the build process fail so it was finding the dll and adding it to the MSI package correctly.  The first line of the custom action being called was a call to launch a debugger so that I could then step through the method and see it in action, this was never being called so it wasn’t even getting this far.


Anyway, I have now cracked this particular problem.  As it happens the library containing the custom action was compiled for .NET 4.0 … as soon as I switched this to either .NET 2.0 or .NET 3.5 all is happy.  All I can assume is that since WiX itself is .NET 3.5 that is the version that is loaded into the process by default.  So when the MSI tried to access my custom action in a .NET 4.0 library it simply bombed the whole process.


Building Installers

If you are ever in a situation where you are building an installer for an application and things have gone a bit awry with the uninstall process (tut, tut) there is a nice simple way to get yourself back on track.  Simply run the command below and this will force an uninstall of the product matching the GUID supplied in the command.

Msiexec /x {your-product-guid-code} IGNORE_PRE_CHECK=1

I’ve not needed this yet but no doubt it’s worth blogging about as it will rear it’s ugly head at some point!