Error 1723 - Urgent Help
hi first post here and hope you guys can help. i created a small package at a customer site who use Wise 7.1 and installer engine 3.1
since creation of package a minor tweak has had to me made, in that a custom action execute from destination line has been added.
back at base we run Wise 7.0 and installer engine 2.0 on our standard build.
i edited the package to include this one custom action line and compiled without issue. however on running the msi the 1723 error "a dll could not be run to complete this function" occurs everytime.
i have done the suggested of updating to installer engine 3.1 but still the error occurs.
my theory is that there is something in the msi that recognises the fact it was initially compiled in a later version (7.1). i also noticed that on compile (in 7.0) the file size reduced.
btw it is not a problem with the custom action line as when created in a bog standard msi with dummy component it runs fine, hence my theory on it being something to do with the downgraded wise version.
any thoughts on this would be most appreciated.
since creation of package a minor tweak has had to me made, in that a custom action execute from destination line has been added.
back at base we run Wise 7.0 and installer engine 2.0 on our standard build.
i edited the package to include this one custom action line and compiled without issue. however on running the msi the 1723 error "a dll could not be run to complete this function" occurs everytime.
i have done the suggested of updating to installer engine 3.1 but still the error occurs.
my theory is that there is something in the msi that recognises the fact it was initially compiled in a later version (7.1). i also noticed that on compile (in 7.0) the file size reduced.
btw it is not a problem with the custom action line as when created in a bog standard msi with dummy component it runs fine, hence my theory on it being something to do with the downgraded wise version.
any thoughts on this would be most appreciated.
0 Comments
[ + ] Show comments
Answers (6)
Please log in to answer
Posted by:
anonymous_9363
15 years ago
What schema is the MSI set to use? If it's '2', then the Wise version used to compile it will be irrelevant.
The error you're seeing is due to a missing DLL. I'd guess that the MSI is originally an InstallShield-authored one, that it contains a number of Custom Actions prefixed with 'is' or 'IS' and that you haven't installed the relevant IS engine/drive beforehand. Most such MSIs have detection for the engine/driver but perhaps this has been removed in this case.
If it's not THAT, then the CA must be calling a function in some other DLL which isn't present on the target. ProcMon will identify it easily.
The error you're seeing is due to a missing DLL. I'd guess that the MSI is originally an InstallShield-authored one, that it contains a number of Custom Actions prefixed with 'is' or 'IS' and that you haven't installed the relevant IS engine/drive beforehand. Most such MSIs have detection for the engine/driver but perhaps this has been removed in this case.
If it's not THAT, then the CA must be calling a function in some other DLL which isn't present on the target. ProcMon will identify it easily.
Posted by:
kasw3670
15 years ago
whoops! got called into a meeting and then went on lunch and forgot i was still logged in.
thanks for the response....
the schema is 2. forgot to mention earlier this is an msi wrapper from a vendor setup.exe (created in inno setup) that does not extract an msi. did the usual setupcapture to try and create an msi but was unsuccessful hence use of wrapper method so that landesk still has an msi it can deploy.
i will look into the ProcMon but why would this be the case that I have to use this if i can run the custom action no problem as a standalone msi? created in Wise 7.0
thanks for the response....
the schema is 2. forgot to mention earlier this is an msi wrapper from a vendor setup.exe (created in inno setup) that does not extract an msi. did the usual setupcapture to try and create an msi but was unsuccessful hence use of wrapper method so that landesk still has an msi it can deploy.
i will look into the ProcMon but why would this be the case that I have to use this if i can run the custom action no problem as a standalone msi? created in Wise 7.0
Posted by:
anonymous_9363
15 years ago
why would this be the case that I have to use thisYou don't have to use it. It has nothing to do with Windows Installer, it's a general purpose file/registry/process monitor. Its purpose is to show you what's missing. My view is well known here, that it is impossible to do this job (or, indeed, any kind of support/operations role) without it or something similar.
Posted by:
kasw3670
15 years ago
no go with ProcMon as sp2 requirement. our build and customer in question is xp sp1. however i thought i would install sp2 anyways and noticed access denied errors server side, as the version of wise we use here is managed centrally on a server with just the bar minimum on the client.
access denied server side with setupwatch.dll, setupwatch.dll and qahook.dll in wisepackagestudio\hook directory.
i am using the same admin account i have always used without issue prior. think i may just start again from scratch this end. would be interested to know if others have experienced issues though when recompiling on downgraded wise versions.
access denied server side with setupwatch.dll, setupwatch.dll and qahook.dll in wisepackagestudio\hook directory.
i am using the same admin account i have always used without issue prior. think i may just start again from scratch this end. would be interested to know if others have experienced issues though when recompiling on downgraded wise versions.
Posted by:
anonymous_9363
15 years ago
IIRC, only v2 requires SP2. Use one of the Web's many archive sources for older versions. Versions 1.26 and 1.30 were available for a long time so should appear somewhere. Also, you could always use something else! All you need to know is, what file and/or registry stuff is missing or permissioned wrongly.
As for your WPS issues, just build some VMs/VPCs, install there, then re-test. The compilation on downgraded versions is a red herring.
As for your WPS issues, just build some VMs/VPCs, install there, then re-test. The compilation on downgraded versions is a red herring.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.