I was preparing installers for DWG Explorer Column Handler (DWG Columns) when I run into problem with the 64-bit versions for Vista and Windows 7. I used Visual Studio 2008, a C++ project and a basic setup project with a couple of custom actions to register and unregister a DLL file. The 32-bit setup worked without problems.
I first got the following error on Vista 64-bit and Windows 7 64-bit.
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 _474A8F1D_82B8_4FC0_8E65_22E8CDBD2B7B, entry: _InstallPropertySchema@4, library:
C:\Program Files\JTB World\DWG Explorer Column Handler\DWGPropertyHandler.dll
After trying to create the setup directly on a 64-bit system I was able to install but the uninstall failed like this.
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 _8B4F6610_75E7_462C_AB3D_BDC92ECCF640, entry: _UninstallPropertySchema@4, library:
C:\Program Files\JTB World\DWG Explorer Column Handler\DWGPropertyHandler.dll
I first figured out that I could edit the MSI file with Orca. In the table CustomAction I found the Actions I needed to change.
This worked good but needed to be done manually each time.
I then tried to use a trick to change how the DLL is built so it will use the correct name. I tried with the following link step in
Visual Studio>Project Properties>Linker properties>Command Line>Additional options
/export:_InstallPropertySchema@4=InstallPropertySchema /export:_UninstallPropertySchema@4=UninstallPropertySchema
And that worked just great. Now I have installers working for XP, Vista, Windows 7 and both 32-bit and 64-bit.
Are you sure this works the way you think? The incorrect name decoration is introduced when building the MSI, not when linking the module that exports the functions. The only way I've ever been able to resolve this bug is to ignore the build warning, then run a postbuild script to correct the name in the MSI database.
ReplyDeleteOwen, thanks for your comment, as far as I have found in my tests it works either way. Using Export makes both the MSI working as expected and I have not found any problems with the program either.
ReplyDeleteWhat problem do you think this might introduce?
I guess I could use WiRunSql.vbs to update the MSI postbuild too instead of manually update it but not sure if it is a better idea or not.
I had already tried this and other permutations in the past, but when I read your post I tried exactly what you suggested with one of my projects, but I still got the same warning.
ReplyDeletePerhaps my case is slightly different (I get "WARNING: Entry point 'MyExportedFunction' not found in module 'MyModule' for custom action 'MyCustomAction'." when building). I am using Visual Studio 2008.
If you were able to get the forcibly renamed function working without warnings, I may need to look more closely at why it failed for me.
Owen, it seems like your case is different as I had no problem to build the MSI. It is first when running the MSI i get the problem (details found in the MSI log file).
ReplyDelete