/build/static/layout/Breadcrumb_cap_w.png

Custom Action to delete folder using InstallShield

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")

ProgramFilesx86=WshShell.ExpandEnvironmentStrings("%PROGRAMFILES(x86)%")

path=ProgramFilesx86 & "\Opas"

Set objFSO = CreateObject("Scripting.FileSystemObject")
objFSO.DeleteFolder(path)

I have tried "immediate execution" and "deffered in system context" but it doesn´t delete the folder and files which it should.

0 Comments   [ + ] Show comments

Answers (4)

Answer Summary:
Posted by: anonymous_9363 8 years ago
Red Belt
3
Use the RemoveFile table to delete folders.

Comments:
  • 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. - Agathorn 8 years ago
Posted by: Pressanykey 8 years ago
Red Belt
1

Top Answer

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

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

to

Set WshShell = CreateObject("Wscript.Shell")







Comments:
  • Thanks that worked out great! I had no idea of this! - Agathorn 8 years ago
Posted by: anonymous_9363 8 years ago
Red Belt
1

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).


Comments:
  • Yeah sorry for not asking the question more precise. I left out some information. Thanks for the explanation! Helpful information! - Agathorn 8 years ago
Posted by: anonymous_9363 8 years ago
Red Belt
0
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.

Comments:
  • 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. - Agathorn 8 years ago
    • 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. - EdT 8 years ago
      • The question is answered already. So case solved! - Agathorn 8 years ago
 
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