I need to call a dll custom action from Basic msi project.I have converted the Basic msi project to support 64 bit installation, but the setup.exe is running as 32 bit process. Now that the dll project is converted to 64 bit, I am getting an exception of msiexec.exe when I run the setup.exe. When I changed back the dll to 32 bit, there is no error. Is there a way to run the setup.exe as a 64 Bit process? I am using Install Shield 2012 Spring Edition.
No; we don't currently offer a 64-bit setup.exe, partly because the failure message (at attempted launch) on 32-bit machines is not very pleasant. (That said, a 64-bit MSI package in a suite is invoked from a 64-bit helper). However setup.exe should call the 64-bit msiexec.exe, so this should not prevent an MSI from including a 64-bit dll or exe in a custom action. Is your dll a native or managed dll? The latter may need some additional coaxing; the former should have a clear message in the verbose MSI log.
Thanks Michael for the reply.I am not sure right now whether the dll is native or managed. I checked the verbose logging, the custom action returns 1 in there. Moreover in my original post I forgot to mention that the dll was also ported to vs 2010 from vc++ 6.0.
The problem has been identified and it is the dll which is creating it. We are using an api localtime. After porting we changed to localtime_s but to support 64-bit platforms , _localtime64_s should be used. So now the exception is not coming and hopefully the issue will be resolved.
Thanks very much for the below informations Michael, it helped to shift the focus to the dll and find the exact cause.However Can you tell me how to find the dll is native or managed, since I could not figure it out.
The most direct way to find out is how you're invoking it - do you have an MSI DLL custom action, or a Managed Code custom action? Other ways to identify this without code include looking at the exports of the DLL (a native DLL is much more likely to have an export which matches the entry point you're calling); loading it in a managed code tool such as ILSpy; and trawling through the PE headers for the .NET headers that only managed DLL files will have. If you do have the code, you can quite easily tell by the way it is built. If it's C# or VB.NET then it's clearly a managed DLL; if it's C++ it's likely to be native (although it's possible to compile C++ as managed by using C++/CLI).
But in short this was a bit of a red herring. The code change you mention suggests to me that you're using native C or C++, and our Managed Code Custom Action machinery was not involved (so it could not have been choosing the wrong architecture).
