Unable to setup with WiX Installer

Question

I created a Setup with WiX Installer for my C# application.

I use a Class CustomAction to install a SQL data base and setting rights to a folder.

There is my Class :

public class CustomActions
{
    [CustomAction]
    public static ActionResult AllowAppData(Session session){...}

    [CustomAction]
    public static ActionResult Install_SetupDataBase(Session session){...}
}

And the product.wxs :

<Binary Id="CASetup.dll" SourceFile="$(var.SetupCustomAction.TargetDir)$(var.SetupCustomAction.TargetName).CA.dll" />
<CustomAction Id="CustomActionSetupAllow" BinaryKey="CASetup.dll" DllEntry="AllowAppData" Execute="immediate" />
<CustomAction Id="CustomActionSetupBase" BinaryKey="CASetup.dll" DllEntry="Install_SetupDataBase" Execute="immediate" />

<InstallExecuteSequence>
  <Custom Action='CustomActionSetupAllow' After='InstallFinalize' />
  <Custom Action='CustomActionSetupBase' After='InstallFinalize' />
</InstallExecuteSequence>

The build is ok but when the Install perform I have the message :

I've try with only CustomActionSetupAllow and it's works fine. But with CustomActionSetupBase I got the message.

How can I know what DLL are missing ? And where should I add a reference ?

Answer 1

The error "could not be run" doesn't mean it's missing. It's in the Binary table of the MSI file and will be streamed out onto disk to run. The error means that it doesn't load and run, or is crashing. It's possible that there are missing dependent Dlls.

One potentially serious problem is that you've marked the custom action (CA) to be immediate. That means it runs before anything has been installed, such as perhaps the empty database you might be populating, as well as any dependent Dlls it might need. Apart from that, if you create the SQL DB with an immediate CA and the install subsequently fails so you'll have a DB but no installed product. It should be a deferred custom action, ideally with a rollback CA to remove the DB so the user can run the install again and you don't populate the same DB again, if that's an issue.

There are other areas you may want to look at. An immediate CA runs with the installing user's credential and not elevated, so if the code requires elevation it will fail. A deferred CA will run elevated with the system account, so access to a SQL DB with the system account might be an issue. Code in a CA needs to be very defensive because it's not the same environment as an interactive test. For these reasons it's often better to do this with a startup program that runs in a true interactive environment when the app first runs.