Hello, I've been browsing the internet for a few days now trying to figure out this solution and I can't seem to find anything. I'm hoping someone here can give me a good pointer or two.

I'm using Wise Installation Studio 7.0 to install software. From within the installation (from within the Execute Immediate to be exact) a VBScript is being called that is supposed to copy 2 files from the installation to another location not associated with the installation directory (there's a whole reason for this, but those details aren't important). The only problem is that the VBScript cannot find the files. So my questions are:


  • How can display output for the VBScript when the installer calls it?
  • What's the best approach for copying files from within a VBScript? I mean, at what point should I call the VBScript so that the files actually do exist?
  • Which MSI Script action should I be calling?

    • Call VBScript from Embedded Code
    • Call VBScript from Installation
    • Call VBScript from Installed Files (what I'm currently using)
    • Call VBScript from Property.


Here is a snippet of the VBScript code that I'm using to copy the files is:
strFilePath = destinationDir & "\file1.dat"
if objFSO.FileExists(strFilePath) = false then
sCurPath = CreateObject("Scripting.FileSystemObject").GetAbsolutePathName(".")
' Debug output
'WScript.Echo sCurPath
strFilePath = sCurPath & "\file1.dat"
' Debug output
'WScript.Echo strFilePath
objFSO.CopyFile strFilePath, destinationDir
End if

strFilePath = destinationDir & "\file2.dat"

' now do the same for the second file
if objFSO.FileExists(strFilePath) = false then
strFilePath = sCurPath & "\file2.dat"
' Debug output
'WScript.Echo strFilePath
objFSO.CopyFile strFilePath, destinationDir
end if


Any and all help would be greatly appreciated.
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
What's the exact scheduling of your script in immediate execution relative to InstallFinalize?
If you absolutely want this script to run in immediate context and after the files are present, you have to schedule it after InstallFinalize.

As for getting some feedback, I believe full logging of the msi should give you more context on where the VBS code fails, I'm not sure though if this is true for all types of custom actions, you might want to try storing the script in the CA or in the Binary Table. Another option is to put in some messageboxes in test phase and run the installer with User Interaction, keep an eye on its execution that way.

Kind Regards
Answered 04/06/2011 by: pjgeutjens
Red Belt

Please log in to comment
0
I'm currently using "Call VBScript from Installed Files" which forces me to make the call after InstallFinalize.

If I look at the MSI log, it tells me the line location the error occured and that the file does not exist (in reference to the code snippet above, that would be the first FileCopy call). Is it possible this call "sCurPath = CreateObject("Scripting.FileSystemObject").GetAbsolutePathName(".")" doesn't work the same within the install? Are there any other ways to get the current directory for the VBScript when the MSI script calls it?

I appreciate your help.
Answered 04/06/2011 by: AgentWorm
Senior Yellow Belt

Please log in to comment
0
I was able to figure out the issue.

This call:
sCurPath = CreateObject("Scripting.FileSystemObject").GetAbsolutePathName(".")was returning "C:\Windows\SysWOW64" (obvious I'm using a 64-bit system).
I changed the call to:
Session.Property("INSTALLDIR")Where INSTALLDIR is a value in the Property table for the MSI installer.

Thanks for the suggestions.
Answered 04/06/2011 by: AgentWorm
Senior Yellow Belt

Please log in to comment
0
You'll find it much simpler to use the MoveFile table in the MSI itself :-)

Also, FFR, if you had to add the CA after InstallFinalize, you were adding it in the ExecuteImmediate sequence. CAs which make changes to the system should be in the ExecuteDeferred sequence. The difficulty with that is that you have access to very few WI properties in that sequence. You thus need to make use of the special CustomActionData property. Look that up here on AppDeploy and on MSDN also.
Answered 04/07/2011 by: VBScab
Red Belt

Please log in to comment
0
You'll find it much simpler to use the MoveFile table in the MSI itself :-)

Would you believe for some reason this completely slipped my mind? Come to think of it tbh I've hardly ever used this table...
Hat's off to you Ian

PJ
Answered 04/07/2011 by: pjgeutjens
Red Belt

Please log in to comment
0
I didn't look into the MoveFile table. Truth be told, prior to Friday, April 1st, I had never used Wise Installation Studio. I picked up this task with no knowledge whatsoever on how it works and needed to get it done ASAP. Also, I should explain fully what I needed to do.

(Some sloppy psuedo code)

Does a certain environment system variable exist?
If it does then
get the value (It will be a file path in this case)
else If it doesn't
Determine what version of windows (32-bit/64-bit) is being used
' so we can use the "C:\Program Files\" or "C:\Program Files (x86)\" and create the file path
' such as "C:\Program Files\DestinationDir"
Add the environment system variable with the path as value

Copy files from installation directory to the system variable file path


I tried doing all of that from within the Installation Expert, but the file transfer was the most difficult part specifically determining how to save it to the system variable location. Are you suggesting that it is possible to do all of this within the Tables?

Thanks for the help and suggestions. :)
Answered 04/07/2011 by: AgentWorm
Senior Yellow Belt

Please log in to comment
0
Are you suggesting that it is possible to do all of this within the Tables? Yup. You would use, for example, [%SystemRoot] to refer to that environment variable. Look up 'Formatted' in MSI.CHM for details on the various prefix symbols for properties.

Good job so far on picking up the reins.
Answered 04/08/2011 by: VBScab
Red Belt

Please log in to comment
0
I'll have to take a look at it more thoroughly and see what else can be done.

Thank you all for your suggestions.
Answered 04/08/2011 by: AgentWorm
Senior Yellow Belt

Please log in to comment
Answer this question or Comment on this question for clarity