NSIS bootstrapper checking results of prerequisite

[adrian0b]

Hi,

I looked at the sources for NSIS bootstrapper and it seems to me, there is no way to implement a check on the return code of a prerequisite .exe installer.

I am dealing with a external driver installer exe that has to be deployed alongside my application. I would like to cancel installation progress if the driver install failed. Or even better - set some kind of return code/ prameter for wixsharp to evaluate. It would be great to have my custom main-msi come up with a message, that the driver could not be installed.

I know i could check on registry entries, but I am not aware of any of those from the proprietary driver installer.

Did I miss something here?

Thank you!
Adriano

[oleg-shilo]

Sorry, I do not have the answer.

But your view of the appropriate algorithm does make sense:

1. Design a routine for detecting the driver presence
2. Run the routine (e.g. before AppSearch action)
3. Feed the result to the msi property
4. In BefireInstall event evaluate the property and either abort or resume the installation.

The real problem is step 1. You may want to try to extend your options to the file system or even driver API (e.g. try to open the driver from C# interop).

[adrian0b]

Actually for Step 1: The driver installer returns a return code 0,-1,etc. . I could check on that and decide on how to continue. In the bootstrapper code however, the return code of the prerequesite is not handled in any way i could see.

Thank you!

[oleg-shilo]

That's why you do step 2 in the MSI, then you do not need your bootstrapper. However, it would only work if your driver is not an MSI installer but other deployment technology.

As an alternative, you can always create a tiny little proxy-launcher for your driver.exe (I assume it is your driver installer).
The launcher (no UI) can execute It can run driver.exe. Save the return code somewhere (e.g. registry or file system).

Then jump to step 4 and in the custom action retrieve the driver.exe return code and decide what to do and how to communicate it to the user.

Why the launcher is better? Because it allows pushing runtime information to MSI. BA only allows pushing compile time information or user input. But it does not allow capturing the output of one package and channelling it to the next msi package.

You can go with the custom BA. Then you can do ANYTHING there. But arguably, it will attract more effort than that 10-lines-code launcher.

[oleg-shilo]

And for the step 4 the samples are:

[oleg-shilo]

Done. v2.1.6 has been released

[adrian0b]

great, will look into it thank you