Problem calling .exe from inside .msi
I use WPS 4.2, and I am trying to call a wise script (.exe) that I created from inside my .msi.
The .exe file is in the execute deferred section, right before the end. I've tried all three options of calling a wise script:
Run WiseScript from Destination
Run WiseScipt from Installation
Run WiseScript from Installed Files
...and they all produce the same error when the .msi is run: Internal Error 2919
The .exe runs if I call it from a mapped drive, but I don't want to do that. I would like to include the .exe in the package and run it locally.
I've never gotten an .exe call to work in my .msi yet, and I want to use them to do several custom actions so I'm hoping someone has seen this and can help.
Thanks
The .exe file is in the execute deferred section, right before the end. I've tried all three options of calling a wise script:
Run WiseScript from Destination
Run WiseScipt from Installation
Run WiseScript from Installed Files
...and they all produce the same error when the .msi is run: Internal Error 2919
The .exe runs if I call it from a mapped drive, but I don't want to do that. I would like to include the .exe in the package and run it locally.
I've never gotten an .exe call to work in my .msi yet, and I want to use them to do several custom actions so I'm hoping someone has seen this and can help.
Thanks
0 Comments
[ + ] Show comments
Answers (3)
Please log in to answer
Posted by:
cdorhout
19 years ago
I found out some additional information on this.
The problem isn't with calling the .exe. It occurs when you place the .exe in the .msi. It compiles just fine, but gives this error when the package is run. Even if the .exe is never called in the package.
I don't know why I can't just throw this .exe into my .msi and run it. I'm confused.
The problem isn't with calling the .exe. It occurs when you place the .exe in the .msi. It compiles just fine, but gives this error when the package is run. Even if the .exe is never called in the package.
I don't know why I can't just throw this .exe into my .msi and run it. I'm confused.
Posted by:
jbonbright
19 years ago
Is this the same issue you were having the other day with the Wise script that runs the cacls command?
Although I routinely call Wise scripts from within WPS-created MSIs, including doing something very similar to what you mentioned with cacls.exe, if you're stuck there are a couple of things I'd try if I were you.
(I'm assuming your Wise script runs fine by itself, even if you have to be logged on with local admin rights in order to run it.)
First, create a brand new MSI that only calls the Wise script and see if that works. To me, the most basic way to do this is to "Run WiseScript from Installed Files." You'll have to install the file in Installation Expert~Files first, of course. Then, insert the "Execute WiseScript from Installed Files" action in the Execute Deferred script just above InstallFinalize, browsing to the file you "installed" on the target. See if that works. If it does, it may suggest that something else is going on with your MSI. (I have run into problems with using "Run WiseScript from Installation" before where the MSI seemed to retain the WiseScript call even when you delete that line of code from the Execute Deferred script, even after recompiling.)
Secondly, instead of calling a WiseScript, you could do an "Execute Program from Installed Files" and run cacls.exe right from there, putting the necessary switches and account info in the Command Line field.
Although I routinely call Wise scripts from within WPS-created MSIs, including doing something very similar to what you mentioned with cacls.exe, if you're stuck there are a couple of things I'd try if I were you.
(I'm assuming your Wise script runs fine by itself, even if you have to be logged on with local admin rights in order to run it.)
First, create a brand new MSI that only calls the Wise script and see if that works. To me, the most basic way to do this is to "Run WiseScript from Installed Files." You'll have to install the file in Installation Expert~Files first, of course. Then, insert the "Execute WiseScript from Installed Files" action in the Execute Deferred script just above InstallFinalize, browsing to the file you "installed" on the target. See if that works. If it does, it may suggest that something else is going on with your MSI. (I have run into problems with using "Run WiseScript from Installation" before where the MSI seemed to retain the WiseScript call even when you delete that line of code from the Execute Deferred script, even after recompiling.)
Secondly, instead of calling a WiseScript, you could do an "Execute Program from Installed Files" and run cacls.exe right from there, putting the necessary switches and account info in the Command Line field.
Posted by:
cdorhout
19 years ago
Yes, I did what you said and created an empty msi and I did get it to work. There must be a whole different problem with the package I was testing this on.
I ran it "WiseScripts from installed files" like you said. I like the idea of the .exe remaining on the clients pc so they can run it again later if permissions get screwed up.
Yes, this does relate to my cacls question the other day, but I'm not using that anymore. I'm using the secedit command to install a custom security template for each package. It works great, plus you can assign permissions on subdirectories and the registry. This is going to save me and my collegues so much time.
Thanks for your help!
I ran it "WiseScripts from installed files" like you said. I like the idea of the .exe remaining on the clients pc so they can run it again later if permissions get screwed up.
Yes, this does relate to my cacls question the other day, but I'm not using that anymore. I'm using the secedit command to install a custom security template for each package. It works great, plus you can assign permissions on subdirectories and the registry. This is going to save me and my collegues so much time.
Thanks for your help!
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.