VBScript CustomAction Error 1720
A bit frustrated at this one.... I've searched over the forums and google, and read through posts but I'm unable to figure this one out [&:]
I put a VBScript into a CustomAction and am getting the following error in the error log;
-----
MSI (s) (B0:C4) [17:15:37:301]: Product: RightFax Client 9.3 -- Error 1720.There is a problem with this Windows Installer package. A script required for this install to complete could not be run. Contact your support personnel or package vendor. Custom action RegSvr_Uninstall script error -2146827864, Microsoft VBScript runtime error: Object required: 'filesys' Line 13, Column 1,
-----
And here is my VBScript;
-----
set oShell = CreateObject("Wscript.Shell")
oShell.Run "RegSvr32 /u /s " & chr(34) & "C:\Program Files\RightFax\Shared Files\English\RFxMSx32.dll" & chr(34)
set ofilesys = CreateObject ("Scripting.FileSystemObject")
If ofilesys.FolderExists("C:\Program Files\RightFax\") Then
set oRightFaxFolder = filesys.GetFolder("C:\Program Files\RightFax\")
oRightFaxFolder.Delete
End If
------
I've read in multiple posts...
Never:
Set wshell = WScript.CreateObject("WScript.Shell")
Always:
Set wshell = CreateObject("WScript.Shell")
It seems like this is generating an error with something to do with filesys???
I seem to be pretty clueless at this point...Any ideas????
I put a VBScript into a CustomAction and am getting the following error in the error log;
-----
MSI (s) (B0:C4) [17:15:37:301]: Product: RightFax Client 9.3 -- Error 1720.There is a problem with this Windows Installer package. A script required for this install to complete could not be run. Contact your support personnel or package vendor. Custom action RegSvr_Uninstall script error -2146827864, Microsoft VBScript runtime error: Object required: 'filesys' Line 13, Column 1,
-----
And here is my VBScript;
-----
set oShell = CreateObject("Wscript.Shell")
oShell.Run "RegSvr32 /u /s " & chr(34) & "C:\Program Files\RightFax\Shared Files\English\RFxMSx32.dll" & chr(34)
set ofilesys = CreateObject ("Scripting.FileSystemObject")
If ofilesys.FolderExists("C:\Program Files\RightFax\") Then
set oRightFaxFolder = filesys.GetFolder("C:\Program Files\RightFax\")
oRightFaxFolder.Delete
End If
------
I've read in multiple posts...
Never:
Set wshell = WScript.CreateObject("WScript.Shell")
Always:
Set wshell = CreateObject("WScript.Shell")
It seems like this is generating an error with something to do with filesys???
I seem to be pretty clueless at this point...Any ideas????
0 Comments
[ + ] Show comments
Answers (14)
Please log in to answer
Posted by:
gmorgan618
17 years ago
Here is a script I use to delete the oracle directories... use it if it helps.
It's not my prettiest, but it works, i think... :)
*** I edited it to make it look a little better... ***
------------- VB SCRIPT ----------------
fnDeleteFolder "C:\oracle\ora81"
fnDeleteFolder "C:\oracle\ora92"
Function fnDeleteFolder(Path)
Dim oFSO : Set oFSO = CreateObject("Scripting.FileSystemObject")
Dim objFolder : Set objFolder = oFSO.GetFolder(Path)
Dim arrFolders : Set arrFolders = objFolder.SubFolders
If Not(arrFolders Is Nothing)Then
For Each Folder In arrFolders
If (oFSO.GetFolder(Folder.Path).SubFolders).Count = 0 Then
If ofso.FolderExists(Folder.Path) Then
ofso.DeleteFolder Folder.Path,TRUE
End If
Else
fnDeleteFolder(Folder.Path)
End If
Next
End if
Set oFSO = Nothing
Set objFolder = Nothing
Set arrFolders = Nothing
End Function
It's not my prettiest, but it works, i think... :)
*** I edited it to make it look a little better... ***
------------- VB SCRIPT ----------------
fnDeleteFolder "C:\oracle\ora81"
fnDeleteFolder "C:\oracle\ora92"
Function fnDeleteFolder(Path)
Dim oFSO : Set oFSO = CreateObject("Scripting.FileSystemObject")
Dim objFolder : Set objFolder = oFSO.GetFolder(Path)
Dim arrFolders : Set arrFolders = objFolder.SubFolders
If Not(arrFolders Is Nothing)Then
For Each Folder In arrFolders
If (oFSO.GetFolder(Folder.Path).SubFolders).Count = 0 Then
If ofso.FolderExists(Folder.Path) Then
ofso.DeleteFolder Folder.Path,TRUE
End If
Else
fnDeleteFolder(Folder.Path)
End If
Next
End if
Set oFSO = Nothing
Set objFolder = Nothing
Set arrFolders = Nothing
End Function
Posted by:
Inabus
17 years ago
Posted by:
gmorgan618
17 years ago
Posted by:
JdotQ
17 years ago
Inabus & gmorgan -- thanks for the replies!
Great catch gmorgan -- I guess staring at it for awhile, I became blind to the typo [:@]
I adjusted the VBScript inside the CustomAction, but it appears that it is not carrying the changes down when going through the uninstall process (according to the logs);
This is what my script appears inside the CustomAction;
----
set oRightFaxFolder = ofilesys.GetFolder("C:\Program Files\RightFax\")
----
And going through the uninstall while logging, the same line appears as this in the log;
----
set oRightFaxFolder = filesys.GetFolder("C:\Program Files\RightFax\")
----
Is there some sort of cache that stores this somewhere? It does not seem to be grabbing the latest (even though the changes are saved to the MST)
*EDIT*
To see the changes take effect during an uninstall procedure, do I need to reinstall? I'm thinking it might cache the CustomActions somewhere locally, as I'm updating the network share where the MSI/MST are being hosted...
Great catch gmorgan -- I guess staring at it for awhile, I became blind to the typo [:@]
I adjusted the VBScript inside the CustomAction, but it appears that it is not carrying the changes down when going through the uninstall process (according to the logs);
This is what my script appears inside the CustomAction;
----
set oRightFaxFolder = ofilesys.GetFolder("C:\Program Files\RightFax\")
----
And going through the uninstall while logging, the same line appears as this in the log;
----
set oRightFaxFolder = filesys.GetFolder("C:\Program Files\RightFax\")
----
Is there some sort of cache that stores this somewhere? It does not seem to be grabbing the latest (even though the changes are saved to the MST)
*EDIT*
To see the changes take effect during an uninstall procedure, do I need to reinstall? I'm thinking it might cache the CustomActions somewhere locally, as I'm updating the network share where the MSI/MST are being hosted...
Posted by:
JdotQ
17 years ago
OK, so I was was somewhat correct -- it caches the MST file locally (within C:\Windows\Installer\{*GUID*})
So I still have the 1720, but the log is something different;
----
MSI (s) (F8:28) [11:31:06:747]: Product: RightFax Client 9.3 -- Error 1720.There is a problem with this Windows Installer package. A script required for this install to complete could not be run. Contact your support personnel or package vendor. Custom action RegSvr_Uninstall script error -2146828218, Microsoft VBScript runtime error: Permission denied Line 8, Column 1,
----
So it appears I don't have rights to delete the folder C:\Program Files\RightFax (line 8 = "oRightFaxFolder.Delete")
I'm running the CustomAction in "Deferred Execution in System Context"...
Any ideas???
So I still have the 1720, but the log is something different;
----
MSI (s) (F8:28) [11:31:06:747]: Product: RightFax Client 9.3 -- Error 1720.There is a problem with this Windows Installer package. A script required for this install to complete could not be run. Contact your support personnel or package vendor. Custom action RegSvr_Uninstall script error -2146828218, Microsoft VBScript runtime error: Permission denied Line 8, Column 1,
----
So it appears I don't have rights to delete the folder C:\Program Files\RightFax (line 8 = "oRightFaxFolder.Delete")
I'm running the CustomAction in "Deferred Execution in System Context"...
Any ideas???
Posted by:
gmorgan618
17 years ago
Change the permissions to that folder when the MSI is installing...
Add Everyone to the permissions list and give it full access.
System should have Admin access to everything... so you shouldn't need to do this. Are there subfolders?
Also check here
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products
Search for the MSI you are installing -- or the reversed GUID if you know it... "InstallProperties" then look at the data for the value of "LOCALPACKAGE"... This is the name of the local MSI cache
which will be in c:\Windows\Installer
Add Everyone to the permissions list and give it full access.
System should have Admin access to everything... so you shouldn't need to do this. Are there subfolders?
Also check here
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products
Search for the MSI you are installing -- or the reversed GUID if you know it... "InstallProperties" then look at the data for the value of "LOCALPACKAGE"... This is the name of the local MSI cache
which will be in c:\Windows\Installer
Posted by:
JdotQ
17 years ago
ORIGINAL: gmorgan618
Change the permissions to that folder when the MSI is installing...
Add Everyone to the permissions list and give it full access.
System should have Admin access to everything... so you shouldn't need to do this. Are there subfolders?
I agree, I wouldn't think I would have to do this when it is running under the System context (which should in turn have access to everything). Yes, there are subfolders. The structure looks similar to;
C:\Program Files\RightFax\
C:\Program Files\RightFax\Shared Files\
C:\Program Files\RightFax\Shared Files\English
It was my understand (and testing) that the VBScript would delete subfolders as well;
set oRightFaxFolder = ofilesys.GetFolder("C:\Program Files\RightFax\")
oRightFaxFolder.Delete
ORIGINAL: gmorgan618
Also check here
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products
Search for the MSI you are installing -- or the reversed GUID if you know it... "InstallProperties" then look at the data for the value of "LOCALPACKAGE"... This is the name of the local MSI cache
which will be in c:\Windows\Installer
Thanks for this info, this is good to know in the future (or the present to troubleshoot this issue [;)])
ORIGINAL: gmorgan618
Here is a script I use to delete the oracle directories... use it if it helps.
It's not my prettiest, but it works, i think... :)
*** I edited it to make it look a little better... ***
------------- VB SCRIPT ----------------
fnDeleteFolder "C:\oracle\ora81"
fnDeleteFolder "C:\oracle\ora92"
Function fnDeleteFolder(Path)
Dim oFSO : Set oFSO = CreateObject("Scripting.FileSystemObject")
Dim objFolder : Set objFolder = oFSO.GetFolder(Path)
Dim arrFolders : Set arrFolders = objFolder.SubFolders
If Not(arrFolders Is Nothing)Then
For Each Folder In arrFolders
If (oFSO.GetFolder(Folder.Path).SubFolders).Count = 0 Then
If ofso.FolderExists(Folder.Path) Then
ofso.DeleteFolder Folder.Path,TRUE
End If
Else
fnDeleteFolder(Folder.Path)
End If
Next
End if
Set oFSO = Nothing
Set objFolder = Nothing
Set arrFolders = Nothing
End Function
Thanks for posting this. I'll give this a shot and let you know how it goes.
Posted by:
JdotQ
17 years ago
OK, so I tried with that script...and....IT WORKS! Great! [:D]
So it must be something in the original script that needed certain permissions to access the folder...
Thanks for all your help gmorgan, it is very much appreciated
Hopefully I can repay you on the forums somehow (but I think I'll need to build up my knowledge first [;)])
I'm giving your post with the script some points, thanks again!
So it must be something in the original script that needed certain permissions to access the folder...
Thanks for all your help gmorgan, it is very much appreciated
Hopefully I can repay you on the forums somehow (but I think I'll need to build up my knowledge first [;)])
I'm giving your post with the script some points, thanks again!
Posted by:
jmcfadyen
17 years ago
you know you probably should be using script to do this.
MSI has built in tables to remove files / folders and registry. Doing what you are doing is heading down the right path to break reference counting.
I would suggest not using VBS to delete files / folders and use what was designed to do the job.
check out
RemoveFile table
Registry Table
and RemoveRegistry
Note: the registry table can also remove registry as well.
MSI has built in tables to remove files / folders and registry. Doing what you are doing is heading down the right path to break reference counting.
I would suggest not using VBS to delete files / folders and use what was designed to do the job.
check out
RemoveFile table
Registry Table
and RemoveRegistry
Note: the registry table can also remove registry as well.
Posted by:
gmorgan618
17 years ago
Directed to Jmcfadyen
Please explain how this would affect reference counting?
Reference counting has to do with shared dlls (or other shared files) ... If another application is using the "Rightfax" directory to install a shared component then I would say the application is flawed anyway.
To explain this to those who don't know what we are talking about... Files can be marked as "Shared" in your installation packages... if that file already exists when the installer runs, then a "reference counter" is incremented by 1... This is so application don't remove a file when other application may need it.... The application removal that sets the reference count to 0 removes the file.
-- If this script was deleting something from the "Common Files" directory I could see a problem.
** Referencing your last response...
Using the RemoveFiles table has nothing to do with a reference count, It removes the file regardless of the Reference Count.
-------------------
-Grant
Please explain how this would affect reference counting?
Reference counting has to do with shared dlls (or other shared files) ... If another application is using the "Rightfax" directory to install a shared component then I would say the application is flawed anyway.
To explain this to those who don't know what we are talking about... Files can be marked as "Shared" in your installation packages... if that file already exists when the installer runs, then a "reference counter" is incremented by 1... This is so application don't remove a file when other application may need it.... The application removal that sets the reference count to 0 removes the file.
-- If this script was deleting something from the "Common Files" directory I could see a problem.
ORIGINAL: jmcfadyen
MSI has built in tables to remove files / folders and registry. Doing what you are doing is heading down the right path to break reference counting.
** Referencing your last response...
Using the RemoveFiles table has nothing to do with a reference count, It removes the file regardless of the Reference Count.
-------------------
-Grant
Posted by:
jib
17 years ago
Posted by:
jmcfadyen
17 years ago
it affects reference counting because you are deleting folders with no concern if other applications are using it.
this is bad practice however in this example unlikely another app would be using those folders.
MSI is built to delete files / folders use the methods designed by MS not custom hacks to get the job done.
this is bad practice however in this example unlikely another app would be using those folders.
MSI is built to delete files / folders use the methods designed by MS not custom hacks to get the job done.
Posted by:
gmorgan618
17 years ago
You're right... it's much better to use an MS provided hack job...
Like i've already said... Using the RemoveFiles Table, pays no attention to Reference Counters. It will remove the file whether the file has a refcount of 1 or 1000 ...
... I agree with you if what you mean is that the MSI should handle the removal of files it installs. -> I took our back and forth as a discussion of "extra" or unmanaged/stranded files(with regards to the current installation), and the method by which they should be takin care of.
Enough time wasted on this ...
Like i've already said... Using the RemoveFiles Table, pays no attention to Reference Counters. It will remove the file whether the file has a refcount of 1 or 1000 ...
... I agree with you if what you mean is that the MSI should handle the removal of files it installs. -> I took our back and forth as a discussion of "extra" or unmanaged/stranded files(with regards to the current installation), and the method by which they should be takin care of.
Enough time wasted on this ...
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
so that the conversation will remain readable.