You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ENVIRONMENT
Using Windows Server 2003 x64, VS2005 SP1, Wix 3.5, Votive, MSI 3.01.4000.3959.
SUMMARY
If I create a C++ Custom Action Project, the MSI installer fails to load the custom action DLL because the DLL version information is missing. I propose that you add the version information by default to all C++ Custom Action Projects (and possibly .NET too) to prevent MSI custom action DLL load failures. The benefit is that this would enable the DLL template to work without any modifications from the start and save developers hours of work tracking down this issue (due to poor MSI reporting it is quite difficult to track down what went wrong in this case).
STEPS TO REPRODUCE
I used VS 2005 with Votive to build a C++ Custom Action project. I made no changes to the template, except renaming the CustomAction1 function to CheckPID.
I then executed the function through a CustomAction, like the one below:
The custom action is triggered from a button, like this:
NOT Installed
The net result was that the setup failed. A look at the logs showed that error 2896 occurred, but the actual reason was not shown. After spending a few hours trying various things, I saw a post that said that executing the custom action from InstallUI and InstallExecuteUI provides more debugging info. I called the action from the InstallUI and InstallExecuteUI sections:
Checking the logs, this showed the regular error 2896 messages and one extra line:
CheckPID: Error 0x80070715: Failed to get file version of custom action dll
Adding the version information resource to the DLL fixed the problem, and the setup ran without error.
I suggest that you include the version information resource in all new projects to prevent similar issues. This is time can be time consuming to diagnose unless you know the "magic" fix: calling from InstallUISequence and InstallExecuteSequence to get good actionable debugging information.
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
ENVIRONMENT
Using Windows Server 2003 x64, VS2005 SP1, Wix 3.5, Votive, MSI 3.01.4000.3959.
SUMMARY
If I create a C++ Custom Action Project, the MSI installer fails to load the custom action DLL because the DLL version information is missing. I propose that you add the version information by default to all C++ Custom Action Projects (and possibly .NET too) to prevent MSI custom action DLL load failures. The benefit is that this would enable the DLL template to work without any modifications from the start and save developers hours of work tracking down this issue (due to poor MSI reporting it is quite difficult to track down what went wrong in this case).
STEPS TO REPRODUCE
I used VS 2005 with Votive to build a C++ Custom Action project. I made no changes to the template, except renaming the CustomAction1 function to CheckPID.
I then executed the function through a CustomAction, like the one below:
The custom action is triggered from a button, like this:
NOT Installed
The net result was that the setup failed. A look at the logs showed that error 2896 occurred, but the actual reason was not shown. After spending a few hours trying various things, I saw a post that said that executing the custom action from InstallUI and InstallExecuteUI provides more debugging info. I called the action from the InstallUI and InstallExecuteUI sections:
Checking the logs, this showed the regular error 2896 messages and one extra line:
CheckPID: Error 0x80070715: Failed to get file version of custom action dll
Adding the version information resource to the DLL fixed the problem, and the setup ran without error.
I suggest that you include the version information resource in all new projects to prevent similar issues. This is time can be time consuming to diagnose unless you know the "magic" fix: calling from InstallUISequence and InstallExecuteSequence to get good actionable debugging information.
The text was updated successfully, but these errors were encountered: