PDA

View Full Version : How to call an exe and get stdout and return value



agshah
05-24-2017, 02:31 PM
Hi all,
Right after the first dialog page where user chooses the installation location and before the user clicks on Install button
on the next page to begin installation, I want to call an exe that is packaged and get its return value and stdout and then
based on the return value display an additional dialog page or not.

So basically, can someone help with below:

1. How do I package an exe and call it before the installation begins ?
2. How do I get the return value and stdout from the invocation of this exe?
3. Based on the return value from this exe, I want to then display an additional dialog or not. How do I achieve this?

thanks for any help.

chad.petersen
05-25-2017, 09:16 AM
You can call just about any EXE that you'd like, but in general all the MSI knows is it called an external process. You'd have to design that external process to feed information back to the installer as there is no way by default for MSI to interact externally with a called program. Can you imagine if they had to design an installer framework to work with all possible computer programs out there - that would be a tall order - so it can't do anything with stdout or a return value unless you feed those back to the installer using something like MsiSetProperty.

If you don't author the EXE yourself - so you can control what it does - probably not much you can do.

Chad

rguggisberg
05-25-2017, 10:03 AM
yeah... pretty much what Chad said... although, as usual... there is a way! If you are adept with custom actions you could pipe the output of the exe to a temp text file and then parse that in the CA and set a property to be used in conditions. Not a simple matter, but can be done. You should clean up after yourself and have the CA delete that file after retrieving the result. To start with (your first question) you would include the exe as a Support file.

chad.petersen
05-25-2017, 10:18 AM
I don't recommend writing to a file from one process and reading it back in another very often because is not a robust solution, but is a decent workaround for those cases where you REALLY need to accomplish something that can't otherwise be done. Sorry if I would never recommend that to another - that's just me.

Chad

Cary R
06-09-2017, 10:59 AM
There is a way, of course. If you have any other way of doing it other than this, I'd recommend it. But here goes:


Use a C# custom action type. It's going to be a major pain in just about any other language. This will require first building the assembly and then setting it up in InstallShield.
Look into the docs for the .Net Process class (https://msdn.microsoft.com/en-us/library/system.diagnostics.process(v=vs.110).aspx)
For the ProcessStartInfo you feed into the Process constructor, make sure to set UseShellExecute to true, as well as RedirectStandardInput (https://msdn.microsoft.com/en-us/library/system.diagnostics.process.standardinput(v=vs.110).aspx)and RedirectStandardOutput (https://msdn.microsoft.com/en-us/library/system.diagnostics.processstartinfo.redirectstandardoutput(v=vs.110).aspx)



The docs I linked for RedirectStandardInput and RedirectStandardOutput have sample code that shows you how to work with the streams.

I have found that there is one case that kills this approach: If the executable filters input (for example shows alternate characters in the case of password input), it will break the standard input redirection. I've never found a way around this issue.

Good luck!