PDA

View Full Version : error -7117 Deferd CA



BigAlbert
07-09-2006, 09:59 AM
Hi,

When trying to create defered CA which calls dll stored in the Binary Table, I'm having the following error:
"error -7117: Custom Action NewCustomAction1 called from Standard dll and stored in Binary table cannot have deferred/rollback/commit execution".

Note that this error wasent been repreduced in 11.5.

Any ideas?

Christopher Painter
07-09-2006, 03:40 PM
Where is the CA sequenced?

BigAlbert
07-10-2006, 03:12 AM
Between InstallInitialize and InstallFinalize.

MartinMarkevics
07-10-2006, 12:59 PM
The reason you get this error is because you are trying to call a deferred CA (using standard .dll).

When calling a non-MSI .dll (i.e. one that doesn't have the MyFunc(MSIHANDLE) entrypoint), InstallShield does the following:

1. Creates a wrapper .dll with the standard MSI entrypoint
2. Put both the .dll from #1 and your .dll in the Binary table
3. When the custom actions gets called, MSI calls the IS wrapper .dll. This in turn extracts your .dll from the binary table and calls the function you specified.

This works great, except that the IS wrapper .dll does not have access to the Binary table during a deferred custom action and thus it cannot extract & call into your .dll. This is why you get the warning.

So, some options you have are to:


Create a new .dll that has a standard MSI entrypoint and call it directly
Use InstallScript code to do perform the same functionality if you don't want to write your own .dll
Call your CA immediate instead of deferred


There are pros and cons for all of these. If you post more details about what exactly your .dll does, perhaps myself (and others) could recommend the best course of action, but it definitely won’t work as it is now.

Christopher Painter
07-10-2006, 02:30 PM
Martin-

I always thought it was cool how the ISDLLBridge could invoke non Type 1 DLL's, but why not extend pattern by taking all of the parameters placed in the dialog into a CUSTOMACTIONDATA property and have the helper DLL read that in, split the data out and pass it to the non-MSI DLL?

Granted you wouldn't be able to support IN/OUT properties doing this but it's better then saying they can't be deferred at all.

Of course now that you can invoke InstallScript without distributing the scripting.msi and setup.exe it gets alot easier to just invoke DLL's using the UseDLL function.

MartinMarkevics
07-10-2006, 04:10 PM
The parameter data is just one piece of it though. Using the CustomActionData, we could definitely pass the data needed to call the actual .dll, but the IS wrapper still need access to the actual .dll you are trying to call into. Currently, this .dll (along with a supporting .ini) is stored in the binary table. Given that, you can't access either of these during a deferred custom action. So, using CustomActionData for the parameter info only solves 1/2 the issue.

Having said that, there are definitely ways we could improve this. We could do something similar to what we now do for InstallScript custom actions in order to carry more than one file within a single .dll. So, the build process would create a single MSI wrapper .dll that has the actual .dll and other supporting data embedded directly within. At runtime it extracts whatever data it needs without having to query the Binary table. I think that would be the best approach. However, if anyone has a better idea, I'm certainly open to suggestions...

Christopher Painter
07-10-2006, 06:33 PM
Sounds good to me. Wish I lived in Chicago so I could help write it... :)

BigAlbert
07-10-2006, 11:33 PM
Thanks for the in depth debate, but some thing I've missed: This was working greate with 11.5 - what went wrong?