Scripting Question

Custom Action to delete folder using InstallShield

04/08/2015 10033 views
Hi all!

I´m doing an MSI-package however I have to clear up the old installationfolder (all files aren´t removed when uninstalling the old MSI). I have written a simple vbs that should take care of it. It works standalone from a commandprompt. However it doesn´t work in the custom action and I cant figure out why. I think it has something to do with the variable %PROGRAMFILES(x86)% however I dont know. Here is the script:

On Error Resume Next
Dim objFSO
Set WshShell = WScript.CreateObject("Wscript.Shell")


path=ProgramFilesx86 & "\Opas"

Set objFSO = CreateObject("Scripting.FileSystemObject")

I have tried "immediate execution" and "deffered in system context" but it doesn´t delete the folder and files which it should.
Answer Summary:
0 Comments   [ + ] Show comments


Answer Chosen by the Author

An alternative if you can't / do not want to use the RemoveFile table is to change

Set WshShell = WScript.CreateObject("Wscript.Shell")


Set WshShell = CreateObject("Wscript.Shell")

Answered 04/08/2015 by: Pressanykey
Red Belt

  • Thanks that worked out great! I had no idea of this!

Community Chosen Answer

Use the RemoveFile table to delete folders.
Answered 04/08/2015 by: anonymous_9363
Red Belt

  • Thanks, it works. However it´s not that clear if there are any subfolders or not under the folder that I want to wipe. And if I understand things correctly I have to specify the exact folderstructure using RemoveFiles table? At least in my experiments with it so far. I´d like to remove *.* (files and folders) under the specified path.

All Answers


Aaaaaaaaaaaaaaaaaaaah! Now it all comes out! :-) The RemoveFile table won't help you here, then, so it's back to script!

I suggest using an embedded script. That will allow you to access MSI properties (hint: the 'Session' object) in order to get the folder name, thus avoiding any problem with 32-bit/64-bit folder names.

One, add the 'force' argument to the DeleteFolder method. Two, remember that for embedded CAs, the script will be using Windows Installer's interpreter (let's call it that) and not Windows Scripting Host. Therefore, you won't be able to use the 'WScript' directive (e.g. in your WScript.CreateObject... line). Confusingly, you *will* be able to create WScript objects, e.g. WScript.Shell. To illustrate, this is valid in an embedded CA:

Set objWshShell = CreateObject("Wscript.Shell")

while this is not:

Set objWshShell = WScript.CreateObject("Wscript.Shell")

Hopefully, it follows that you can't then use things like WScript.Echo and WScript.Sleep in such CAs.

Script executed by calling CSCRIPT.EXe has no such restrictions but, conversely, can't natively "see" MSI properties. They would need to be passed to such a script, perhaps as command line argument(s).

Answered 04/08/2015 by: anonymous_9363
Red Belt

  • Yeah sorry for not asking the question more precise. I left out some information. Thanks for the explanation! Helpful information!
This content is currently hidden from public view.
Reason: Removed by member request For more information, visit our FAQ's.
This content is currently hidden from public view.
Reason: Removed by member request For more information, visit our FAQ's.
I always go the "belt and braces" route and populate the table with every folder in the tree that needs to be removed, using wildcards as the filename.
Answered 04/08/2015 by: anonymous_9363
Red Belt

  • The issue here is that we don´t really know the name of the subfolders as the application seems to create them differently on each computer after install.
    • Just a thought - are you sure that the folders will be empty? Even a single file in the folder will prevent deletion of the folder.
      • The question is answered already. So case solved!
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ