I have a couple of custom actions in a DLL that I want to call as part of an installation. I have 2 identical kits, one for the x86 build and one for the x64. The differences are that the 64 bit kit has the target platform set to x64 and the 64 bit kit takes program output from a 64 bit build rather than x86.

The x86 build works the x64 build doesn't.

WARNING: Entry point 'Commit' not found in module 'd:\Home\Development\StrawberryFields\InstallationKit\InstallationActions\WIN64\Release\InstallationActions.dll' for custom action 'Primary Output from InstallationActions (Release x64)'.


The actions are defined correctly and are being exported. But then again the 32bit code wouldnt work if they weren't.


I have also found the same problem with sample code from http://bonemanblog.blogspot.com/2005/11/custom-action-tutorial-part-ii.html

I understand that there are problems with script based custom actions, but apparently a plain old boring DLL will work
http://msdn2.microsoft.com/en-us/library/Aa367428.aspx

So how do I do it? preferably without using Orca - I dont really want to have to hack the msi every time I build the kit.

Alternatives? Wix has way to big a learning curve - the WAR front end to Wix is another battle entirely.

As a worst possible alternative would it be possible to use a 32bit custom action to launch a 64bit app that contains the action I want to run **cough hack cough**

Check that the entrypoint really is exported with http://dependencywalker.com/ x64 tool. There are said to be some issues with manifest generators not working properly on some systems.

Have done that - it is exported - and the x86 build of the custom actions works with the x86 installer

Heath Stewarts Blog refers to a similiar problem

http://blogs.msdn.com/heaths/archive/2006/02/01/64-bit-managed-custom-actions-with-visual-studio.aspx

"Back to the problem. When you build the Windows Installer project in Visual Studio 2005 it embeds the 32-bit version of InstallUtilLib.dll into the Binary table as InstallUtil. When Windows Installer executes your managed custom action it actually is calling the ManagedInstall entry point function from InstallUtilLib.dll as a type 1 deferred custom action (1025) which creates an instance of the CCW System.Configuration.Install.IManagedInstaller interface and runs your Installer classes. Since the native InstallUtilLib.dll is 32-bit it loads the 32-bit Framework which will throw the BadImageFormatException since your managed class library is 64-bit."

My custom actions are simply in a C++ 64 bit DLL which i understood bypasses all the issues with script and managed code in installers

More on this one

Diving into Orca - the CustomActions table on the 32 bit build refers to the entry point "Commit" but the custom action table produced by the 64 bit build refers to the entry point of "_Commit@4" which is interesting because I have explicitly checked that the entry point is "Commit" in the EntryPoint property.

My thoughts are that the 64bit project is assuming that entry points are in a certain format and that the recommendation that you explicitly export the entry points via a .def file conflicts with this. So next step is remove the .def file to allow the dll to be built with "natural" exported names and see what happens

Stay tuned.....

Well that turned out to be a red herring. You can get the 32bit build to be able to pick up decorated functions such as _Uninstall@4 via __declspec(dllexport) as well as undecorated functions via an explict export in .def at the same time. The 64 bit build simply won't cooperate.

Any ideas?

Yes, Heath's blog is about managed code installer class custom actions that require a shim Dll - this shim Dll gets called as a type 1 custom action (it's C++) and it then cranks up the runtime and reflects on assemblies to createthe installer class objects. He's pointing out that the shim is a 32-bit Dll. That's not your issue because you have a native C++ Dll.

If you correct it with Orca, does it work? Make the entrypoint name correct and try it?

Hi

I have a Win32 dll that exports functions that i am using in the installer cutom actions.

Below are the signature of functions

UINT __stdcall InstallCA(MSIHANDLE hInstall)

UINT __stdcall Rollback(MSIHANDLE hInstall)

UINT __stdcall Uninstall(MSIHANDLE hInstall)

this is working fine on x86 configuration settings but getting following warnings with 64-bit settings.

WARNING: Entry point 'Uninstall' not found in module 'c:\SUNIL TP\Windows enhancement\CVS_AD\persistent\agentcode\enterprise\persistant\Agent\CADll\x64\Release\CADll.dll' for custom action 'Primary Output from CADll (Active)'.

WARNING: Entry point 'InstallCA' not found in module 'c:\SUNIL TP\Windows enhancement\CVS_AD\persistent\agentcode\enterprise\persistant\Agent\CADll\x64\Release\CADll.dll' for custom action 'Primary Output from CADll (Active)'.

WARNING: Entry point 'Rollback' not found in module 'c:\SUNIL TP\Windows enhancement\CVS_AD\persistent\agentcode\enterprise\persistant\Agent\CADll\x64\Release\CADll.dll' for custom action 'Primary Output from CADll (Active)'.

Moreover installation is getting crashed with followinf error

Product: ADAgentInstaller -- Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action _9D3A934B_47A6_4009_92EA_3C8350212185, entry: _InstallCA@4, library: C:\Program Files\AccessData\Agent\CADll.dll

Any help is higly appriciable

Try using a .DEF file to name the exported functions. I've seen this kind of thing before and using a .DEF file is worth a shot. If there's any name mangling going on, a .DEF file should help.

I assume that you have the x64 C++ runtimes installed on the system before you run the setup?

For the 64bit builds, I had to add a parameter tothe link step to
create a function export name that msiexec is expecting.
So, if you have a function named MyExportFunc1, in visual studio, go into
the Linker properties->Command Line->Additional options: windows and paste
/export:_MyExportFunc@4=MyExportFunc

For details on this trick, see
http://msdn.microsoft.com/en-us/library/tyx5b79y.aspx

I hope this helps someone else because it was a real tough one for me to figure out. Although (as always, right)once I knew the fix, it was obvious :-)