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
- :
- Re: 64bit Installer Class acting as 32bit
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
‎Aug 21, 2010
01:19 PM
64bit Installer Class acting as 32bit
Hi,
I have just upgraded a project to 2011.
The change to the Option .NET tab is most welcome in that you can now define a location for the .NET Framework for both 32 and 64 bit. Unfortunately it doesn't seem to work for me.
The only way I can get my 64bit Installer Class to use the 64bit InstallUtilLib is by setting a path to the 64bit Framework in both the 32bit and 64bit fields. Can anyone confirm this issue?
My project is set to x64 so should be picking up that I need the 64bit Framework.
The whole 32/64bit experience is not great in Installshield. We have a project that needs to be created for both 32 and 64 bit platforms - it is all perfectly possible - it's just too painful at the moment... configuration release flags, custom actions for setting ProgramFiles folders, .NET versions...
Thanks in advance,
Adam
I have just upgraded a project to 2011.
The change to the Option .NET tab is most welcome in that you can now define a location for the .NET Framework for both 32 and 64 bit. Unfortunately it doesn't seem to work for me.
The only way I can get my 64bit Installer Class to use the 64bit InstallUtilLib is by setting a path to the 64bit Framework in both the 32bit and 64bit fields. Can anyone confirm this issue?
My project is set to x64 so should be picking up that I need the 64bit Framework.
The whole 32/64bit experience is not great in Installshield. We have a project that needs to be created for both 32 and 64 bit platforms - it is all perfectly possible - it's just too painful at the moment... configuration release flags, custom actions for setting ProgramFiles folders, .NET versions...
Thanks in advance,
Adam
(5) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 23, 2010
04:57 AM
Hi,
Just to add a little more information regarding this.
The dll I am using is actually compiled as AnyCPU. It's function is to add some complex registry information and needs to read/write to the HLKM\Software hive. We were relying on the fact that if the dll is called using the 64bit version of InstallUtilLib then it would use the 64bit registry area rather than the WOW6432Node.
I was wondering whether Installshield is using the bitness of the dll rather than the Template Summary x64 setting?
Regards,
Adam
Just to add a little more information regarding this.
The dll I am using is actually compiled as AnyCPU. It's function is to add some complex registry information and needs to read/write to the HLKM\Software hive. We were relying on the fact that if the dll is called using the 64bit version of InstallUtilLib then it would use the 64bit registry area rather than the WOW6432Node.
I was wondering whether Installshield is using the bitness of the dll rather than the Template Summary x64 setting?
Regards,
Adam
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 23, 2010
09:06 AM
Do you have the DLL marked as the key file and the component 64bit flag set to Yes?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 23, 2010
09:29 AM
Hi Marwan,
Thanks for the reply.
Yes, the DLL is marked as a key file but no the component is not marked as 64bit.
As I need it to be installed and run for both my 32 and 64 bit installers, do I have to duplicate the component, mark one as 64bit; create 2 features with release flags for 32/64bit and then associate each component with the relevant feature?
Best regards,
Adam
Thanks for the reply.
Yes, the DLL is marked as a key file but no the component is not marked as 64bit.
As I need it to be installed and run for both my 32 and 64 bit installers, do I have to duplicate the component, mark one as 64bit; create 2 features with release flags for 32/64bit and then associate each component with the relevant feature?
Best regards,
Adam
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 23, 2010
09:32 AM
Yes, you need to create 1 component for 32bit and 1 component for 64bit as the 64bit .NET processing works off the 64-bit component flag...
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 23, 2010
09:49 AM
Marwan,
Thanks for the clarification. I will give this a go.
I think the .NET Framework location should not be in the General Options Area of the product. We have a mixture of .NET framework requirements for all the different products we create and so should be able to set it per project.
That was the problem before with the single .NET Framework location. I would go to an entirely different project that couldn't be 64bit and if I was not careful I would end up building on 64 when I didn't want to!
Thanks again,
Adam
Thanks for the clarification. I will give this a go.
I think the .NET Framework location should not be in the General Options Area of the product. We have a mixture of .NET framework requirements for all the different products we create and so should be able to set it per project.
That was the problem before with the single .NET Framework location. I would go to an entirely different project that couldn't be 64bit and if I was not careful I would end up building on 64 when I didn't want to!
Thanks again,
Adam