Custom Action Error 1720 delete files

[pauldennis]

hello,

I am running into further problems deleting files. I have a custom search action searching for a file and if the file exists I want to delete.
the installer runs and I get the error message "script cannot be executed" however the file "Sap3.4DR" is deleted so therefore the search is working okay.

the execution condition is "SAPDR_VIRTUAL ~>< "Sap3.4DR"" so if the file exists in the search path it is deleted.

any ideas?

regards
Paul

from the log file
MSI (s) (88:FC) [09:47:52:138]: Executing op: ActionStart(Name=DELSAPDR,,)
Action 9:47:52: DELSAPDR.
MSI (s) (88:FC) [09:47:52:138]: Executing op: CustomActionSchedule(Action=DELSAPDR,ActionType=3078,Source=' VBScript source code revised for file missing this works but not vista
'---------------------------------------
Dim filePath
filePath = Session.Property("CustomActionData")
Set objFSO = CreateObject("Scripting.FileSystemObject")
If objFSO.FileExists(filePath) Then
objFSO.DeleteFile(filePath)
End If
'---------------------------------------,Target=YourFunction,CustomActionData=C:\Users\paul dennis\AppData\Local\Virtualstore\ProgramData\Complete Picture\Sap3_2\Sap3.4DR)
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 script error , : Line , Column ,
MSI (s) (88:A0) [09:47:53:942]: Product: Sap3_2 -- 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 script error , : Line , Column ,

Action ended 09:47:53: InstallFinalize. Return value 3.

[gigi]

Hi,

We cannot reproduce the problem you are encountering on our test computers. For more investigation please send us the AIP file (if does not contain any confidential information) or a small similar test case to support at advancedinstaller dot com.

Regards,
Gigi

[pauldennis]

Hello Gigi,

I have changed the custom action execution properties to "synchronised ignore return code" and now it seems to work okay. Does this make sense to you?
Regards
Paul

[Cosmin]

Hi Paul,

I have changed the custom action execution properties to "synchronised ignore return code" and now it seems to work okay.

Please note that this option makes Windows Installer ignore the return value of the custom action. For example, if the custom action fails the install continues. Note that this doesn't solve the problem you are encountering.

I noticed that the custom actions in the old version don't use conditions for the install process type (first time install, uninstall or upgrade). This means that the custom actions may be executed in the wrong install process. I also noticed in the log with the error that the custom action with the problem runs during the uninstall of the old version, not during the install of the new package.

The upgrade log contains this line:

Code: Select all

Target=YourFunction,CustomActionData=C:\Users\paul dennis\AppData\Local\Virtualstore\ProgramData\Complete Picture\Sap3_2\Sap3.4DR)

Basically, the DELSAPDR, DELSAPDD and DELSAPDC custom actions in the old version are calling the "YourFunction" function from the VBS file. Since this function doesn't exists in your VBS code, the first custom action fails.

Please note that the "Function Name" field in the "Custom Action Properties" pane should be set to something only if the VBScript code contains a function. Otherwise, the field needs to be empty.

To fix the problem you can try the following:
- make sure that the custom actions I mentioned don't use a function name in both the old and new versions
- condition the custom actions to run in the correct install processes

The first time install condition is:

Code: Select all

(Not Installed)

and the uninstall condition is:

Code: Select all

(REMOVE = "ALL") 

Regards,
Cosmin

[pauldennis]

Hello Cosmin,

thanks for spotting the error is occurring on the uninstall of the previous version I hadn't thought about that. the "yourfunction" typo occurred because AI automatically fills in the field when you choose a new vbs script. The version prior to that didn't include the error, bit frustrating.

Can you explain your comment "condition the custom actions to run in the correct install processes"

I do not understand syntax. Where do I set the install condition?

thanks
Paul

[Cosmin]

Hi Paul,

The condition of a custom action can be set in the "Expression" field from the Custom Action Properties pane. If a custom action doesn't use a condition, it will run every time an install process runs (first time install, upgrade, unistall, repair or modification).

Regards,
Cosmin

[pauldennis]

Thats what I thought. At the moment I have an expression as follows

SAPDR_VIRTUAL ~>< "Sap3.4DR" to check if the file exists.

Cant see how to add another condition

Regards
Paul

[Cosmin]

Hi Paul,

To merge multiple conditions you can use the AND operator. For example, an uninstall custom action can use this condition:

Code: Select all

(SAPDR_VIRTUAL ~>< "Sap3.4DR") AND (REMOVE = "ALL")

Regards,
Cosmin

[pauldennis]

Hello Cosmin,

I think I've found out the hard way how MSI is working. I didn't realise that the original installer was stored on the user's machine and used to remove an existing version when you upgrade to the later version. Therefore I have a problem because we have distributed an installer which has an error on uninstall as described above. so currently the situation is as follows.

Users have version 3.22 and some of these will have the installer with the error. I have updated to version 3.23 and generated a new product code. I have the option to "automatically upgrade" selected but we get the error when uninstalling.

Any idea how can resolve this problem? is there something in the upgrade options that will help?

Regards
Paul

[Cosmin]

Hi Paul,

If the original installation cannot be uninstalled manually, the upgrade process will also be unable to uninstall it. A solution would be to fix the original MSI and recache it on the machines with the problem. After this, the uninstall should work correctly.

To distribute the fix, you can repair the original MSI and add a bootstrapper to it. The bootstrapper can use the re-caching command line to let the user simply run the EXE.

Regards,
Cosmin

[pauldennis]

Hello Cosmin,

Can I achieve this when upgrading users ?
REgards
Paul

[pauldennis]

Hello Cosmin,

I think I've got it. can I clarify how msi decides upon caching. Does it use the product code to decide to cache or is it the name of the msi ?therefore if I change the product code the command line will not re-cache the existing msi with the error.
Also when using the command line for example in our case msiexec /fv sap3_21.msi can I think embed the msi anc cab in the exe file ?

regards
Paul

[Cosmin]

Hi Paul,

Can I achieve this when upgrading users ?

As long as the original package is not modified to much and the installation logic doesn't change, this shouldn't be a problem.

can I clarify how msi decides upon caching. Does it use the product code to decide to cache or is it the name of the msi ?

To recache the original MSI the ProductCode and the package name should remain the same. This also applies to any other GUID in the package. In the original MSI you should modify only the custom actions with the problem.

Also when using the command line for example in our case msiexec /fv sap3_21.msi can I think embed the msi anc cab in the exe file ?

Unfortunately the Advanced Installer bootstrapper cannot be used for this (I apologize for the confusion). However, you can create your own bootstrapper which runs the command.

Regards,
Cosmin

[pauldennis]

hello Cosmin,

I have resolved this using an external .exe to run the recache. in case anyone has the same problem this is how I fixed it.

Repaired the faulty which had the custom action was causing the problem on uninstall using the sign version product code
set the media options for this file to use an external cab, this way you just get a small msi file.

created the upgrade msi with a new product code and the new files.

created a .exe which copied the original msi to the usra temporary folder and then run the re-cache command
msiexec /fv <path_to_new_msi> then copy the upgrade msi to the use a temporary folder and executed that.

The install process and completed okay.

I would like to comment that these problems were caused because we reorganised some files on the server and this meant the path to the vbs script had changed in the custom action. when you try and select the new path to the same vbs AI automatically inserts "your function" into the function field. I strongly suggest you reconsider this type ahead behaviour or check for the "your function" phrase when building and post an alert. I checked another installer script and I had also created the same problem there. is a very easy mistake to make.

thank you for your help. Regards Paul

[Cosmin]

Hi,

I'm glad the problem is solved.

when you try and select the new path to the same vbs AI automatically inserts "your function" into the function field. I strongly suggest you reconsider this type ahead behaviour or check for the "your function" phrase when building and post an alert.

We will consider improving this in a future version of Advanced Installer. Thank you for your suggestion.

Regards,
Cosmin