I have written a deferred C++ DLL CA for a basic MSI (I'm NOT using ISscripting).
When I execute the MSI, I get:-
"<path to temp dir>\<name of dll>" cannot be found. Make sure the file is on the target or installed already.
Indeed, the file is absent from the temp dir, but is in the SUPPORTDIR.
The curious thing is I successfully call another function in this DLL just before the offending CA falls over.
Both functions have the same syntax. Both are exported. The DLL has no missing dependencies.
Watching the temp directory, the DLL is unpacked into the temp dir, but after a few seconds and is then removed.
Has anyone seen (and fixed) this one before?
This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
'temp\xxxx.dll" cannot be found.
Started by
jonks2003
, Oct 13 2004 01:58
2 replies to this topic
jonks2003
-
- Members
- 2 posts
Posted 13 October 2004 - 23:33
Solved!! - But I'm not convinced!
I was creating CAs as standard DLL CAs, when I should have been creating them as MSI DLLs.
Recreating the CAs as MSI DLLs got rid of the runtime error mesage
However, I'm not sure why the CA type should cause the error.
The runtime handling of the DLL file (and\or search path) must be subtley different.
I was creating CAs as standard DLL CAs, when I should have been creating them as MSI DLLs.
Recreating the CAs as MSI DLLs got rid of the runtime error mesage
However, I'm not sure why the CA type should cause the error.
The runtime handling of the DLL file (and\or search path) must be subtley different.
Zweitze
-
- Full Members
- 522 posts
Posted 15 October 2004 - 09:06
Standard DLL CAs get a wrapper by InstallShield. This wrapper actually extracts the DLL from the Binary table, retrieves the properties that were listed as parameter, and calls the requested function.
However, during deferred CAs only a very limited access to the installer package is allowed. In this case, the InstallShield wrapper fails because it cannot extract the DLL from the Binary table, and retrieve the properties.
Another solution was scheduling the CA after InstallFinalize.
However, during deferred CAs only a very limited access to the installer package is allowed. In this case, the InstallShield wrapper fails because it cannot extract the DLL from the Binary table, and retrieve the properties.
Another solution was scheduling the CA after InstallFinalize.