This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- How to run setup.exe as a 64 bit process
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 22, 2013
01:26 AM
How to run setup.exe as a 64 bit process
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.
Regards,
SG
I am using Install Shield 2012 Spring Edition.
Regards,
SG
(4) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 24, 2013
09:05 AM
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 28, 2013
01:48 PM
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 30, 2013
09:33 AM
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.
Regards,
SG
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.
Regards,
SG
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 01, 2013
03:32 PM
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).
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).
![](/skins/images/8CE4FAD0DE6F3A6F9D0567434D2D2DAE/responsive_peak/images/icon_anonymous_message.png)