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"/>
</Fragment>
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.
System.Diagnostics.Debugger.Launch();
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.
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"/> </Fragment>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.