Problem with DLL Custom Action

[Stefan1234]

Hi there,

we're having trouble with one of our new IS2011 Setups.
The Setup is cancelled (Rollback) when one of our DLL Custom Actions fails.
An error message is shown:

"File '%Temp%\_is6.tmp' can not be found. Make sure the file is on target system or installed already."

Our Custom DLL is responsible for adding a firewall exception for our Program to the Windows Firewall (DLL stored in binary table).

I'm not sure, if the error occurs because there is a failure with our Setup itself or one of our Dll's dependencies is not fullfilled. The problem is, we don't have a system here where the Installation fails. Any ideas?

On the other hand, this is just a Nice-to-Have feature and we would like to continue with the installation whether it succeedes or not. Can that be achieved by changing the Return Processing to "Synchronous (Ignore Exit Code)"?

Attached you can find a screenshot with my settings for the dll custom action.

Regards, Stefan

[MSIYER]

Physical presence of the dll file is needed for the CA(Custom Action) to work on the end-user machine. So we two situations:
1) Include the dll as a component. In which case, the dll remains on the end-user machine.
2) Put the dll into the Binary table of the package. Windows Installer engine will stream it out to the temp folder and use it during the install.

Option 2), I believe, is what you need. In case you are trying to execute option 1), configure the CA to run after the InstallFinalize action.

You can also use ISSetup table for the purpose(secondary approach).

[Stefan1234]

MSIYER wrote:

2) Put the dll into the Binary table of the package. Windows Installer engine will stream it out to the temp folder and use it during the install.

That's what I did...

[MichaelU]

Since you are including the .dll in the binary table, chances are the error message isn't exactly what it seems like. Unfortunately, attempts to load a dll that has an unsatisfied dependency return an error code identical to attempts to load a .dll that is itself missing. If you have access through a cooperative customer, you could try running the dependency walker on an extractd copy of your .dll to see if it surfaces any missing dependencies that are not missing in your internal environment. Alternately you could look at the list of .dlls your .dll links to, and consider removing the link, and replacing it with calls to LoadLibrary and GetProcAddress, or delay loading.

If you can identify the scenario where this will occur (e.g. Windows XP before SP2), consider modifying the condition on your custom action (e.g. VersionNT > 501 OR (VersionNT = 501 AND ServicePackLevel >= 2)). Also consider rewriting your action as a "msi .dll" custom action so you can write to the log file. If neither of those are possible or reasonable for your situation, then yes, changing it to ignore exit code will allow the installation to proceed. Of course the action itself may then fail to make its changes and the installation will be unaware.

[Stefan1234]

Hi Michael,

I agree with you and am of the opinion that the load of a dependency fails. Still a first look at a Dependency Walker logfile didn't show me any obvious errors. I might have to take a closer look.

Our Setup won't start on a system less than XP SP2. I think for now we will stick with running the custom action in silent mode and ignoring the exit code.

Thank you!

Stefan