Software Deployment

We will need additional information to fix this.

1) What is the script your running?
2) What sequance is it set too?
3) Is the INI file your after reading deployed as part of the installation.

Paul

1) I execute a script VBS and I execute after InstallFinalize
2) The INI File is not deployed after the installation.

the product that I do use is Wise Package Studio, I read that sometimes Wise did not interpret the Wscript order well when a script VBS was executed, is this truth?

I would move the script to before Install Finalise not after, see if that helps.

Paul

I had already tested what you proposed and that still does not go. I also tested other methods to execute script and it is similar.

Julien

Please post the code.

Regards,

hi julien

whats the error code that you get

if you script runs manually without any errors and it executes the logic in your vbs script

then it should work in the msi


how did you sequence the custom action
what condition did you set
what processing options did you choose

Hi,

You may be having problems with the Wscript option in VBScript. Wise doesn't like this.
check through your code and ensure you con't have any Wscript options, i.e WScript.Echo etc. Wise doesn't like these. What is the error code? Could we see the Script?

To clarify, it's not that Wise doesn't like it but the Installer engine which contains its own scripting runtime and knows nothing of the WScript object. Thus, any MSI authoring tool would choke on WScript directives. Maybe one day, the vendors will build in parsers which will flag this type of error at compile-time. Everybody, begin holding breath.........NOW!

VbScab is right on, the runtime in Wise only has a subset of the abilities. The easy way around this to have your custom action just launch a WiseScript that launches your VBScript.

VbScab is right on, the runtime in Wise only has a subset of the abilities. The easy way around this to have your custom action just launch a WiseScript that launches your VBScript.
That's easy?!? :) It's easier to add the script to the installation, using 'Call VB Script from Installation', such that it gets stored in the Binary table.

Note that I said easy way around the issue, not best practice or the way WPS should actually work.

I still disagree that your course of action is easy, as the OP now has to find out about how to use WiseScript. He can take his external script and 'import' it into the Binary table in seconds without having to go near WiseScript.

I was not assuming that the OP did not have experience with WiseScript.

Nevertheless since he already did the steps that you are suggesting, I thought I would be easier than re-writing a perfectly good script in a limited runtime of Vbs. Perhaps you have some knowledge you could share of exactly which commands WPS restricted from their runtime, I have found it every troublesome to get working VB code rewiten correctly to continue to work once its in WPS. Please share.

Now that IS easy :) Any time you might go to write "WScript[dot]something", such as "WScript.Echo" it won't work. I have previously posted code here which allows packagers to have one script which can work externally and internally, by testing for the 'Session' object and seeting a Boolean. Your code then just needs to test the Boolean and branch accordingly. Using WScript.Echo as an example, the script would still use that directive if Session wasn't an object but write to the install log (if logging is enabled, of course) if it was.