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: Fundamental 64Bit Installation Question
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
‎Nov 19, 2008
02:17 PM
Fundamental 64Bit Installation Question
Hello everyone, I did a brief post search here - couldn't find anything, and so, I have some questions about 64bit Installations.
One of the things that InstallShield 2009 supports is 64bit Installations. For each component there is a 64bit component flag that I can set to Yes to specify that it is 64bit.
The Template Summary property specifies platform and language, thus In General Information -> Summary Information Stream you can specify Intel; 1033 or x64;1033. Also you can override this value by specifying a different product configuration.
Another feature InstallShield has is the release flags property for a feature. You can specify a flag to include that feature at build time and exclude others that don't have that release flag.
Also in InstallShield in General Information/ Product Properties you can specify the INSTALLDIR varaible to [ProgramFilesFolder] or something else such as [ProgramFiles64Folder].
I'll pose my question with the problem.
I have two features, one with a release flag of x64 and one Win32. I have two different product configurations that override my Template Summary. However, in my project I have my INSTALLDIR set to ProgramFilesFolder. So my Installations on a 32bit system install to Program Files and for 64 bit installations it installs to Program Files(x86). It seems as though that while all of these features are nice to have, it really doesn't matter. It seems as though that I need two different Projects, one for 32 and one for 64.
I have read other threads where people in InstallScript try to swap out the value of INSTALLDIR to [ProgramFiles64Folder] and it ends up reverting back. I don't want to do this, esp if it is going to fail anway.
So, Do I need to have two different projects?
Also I want to specify that my project is mainly a .Net project Install. I specify the .Net Framework 3.5 and it installs .Net related components and it installs a speciific 64bit binary written in C++. So I have two features, One feature with a set of components that include my .Net Libraries and the 32bit Component for my 32bit dll with a release flag of Win32. The other features has all of the same components just with a different component (has a different componentcode) that contains the same dll, just a 64 bit build of it. This feature has a release flag of x64.
So on build I have a product configuration that overrides my Template Summary to Intel;1033 and it compiles my release flag of Win32, including the Feature that has my 32bit build. Then I have another product configuration that overrides my Template summary to x64;1033 and with my release flag of x64, thus including my other feature with my 64bit component (set to 64 bit component = yes). If I compile the x64 product configuration, it is still putting my files in Program Files(x86). Now my INSTALLDIR is still set to [ProgramFilesFolder]. This is why I am thinking I am gonna need two different projects for this.
One of the things that InstallShield 2009 supports is 64bit Installations. For each component there is a 64bit component flag that I can set to Yes to specify that it is 64bit.
The Template Summary property specifies platform and language, thus In General Information -> Summary Information Stream you can specify Intel; 1033 or x64;1033. Also you can override this value by specifying a different product configuration.
Another feature InstallShield has is the release flags property for a feature. You can specify a flag to include that feature at build time and exclude others that don't have that release flag.
Also in InstallShield in General Information/ Product Properties you can specify the INSTALLDIR varaible to [ProgramFilesFolder] or something else such as [ProgramFiles64Folder].
I'll pose my question with the problem.
I have two features, one with a release flag of x64 and one Win32. I have two different product configurations that override my Template Summary. However, in my project I have my INSTALLDIR set to ProgramFilesFolder. So my Installations on a 32bit system install to Program Files and for 64 bit installations it installs to Program Files(x86). It seems as though that while all of these features are nice to have, it really doesn't matter. It seems as though that I need two different Projects, one for 32 and one for 64.
I have read other threads where people in InstallScript try to swap out the value of INSTALLDIR to [ProgramFiles64Folder] and it ends up reverting back. I don't want to do this, esp if it is going to fail anway.
So, Do I need to have two different projects?
Also I want to specify that my project is mainly a .Net project Install. I specify the .Net Framework 3.5 and it installs .Net related components and it installs a speciific 64bit binary written in C++. So I have two features, One feature with a set of components that include my .Net Libraries and the 32bit Component for my 32bit dll with a release flag of Win32. The other features has all of the same components just with a different component (has a different componentcode) that contains the same dll, just a 64 bit build of it. This feature has a release flag of x64.
So on build I have a product configuration that overrides my Template Summary to Intel;1033 and it compiles my release flag of Win32, including the Feature that has my 32bit build. Then I have another product configuration that overrides my Template summary to x64;1033 and with my release flag of x64, thus including my other feature with my 64bit component (set to 64 bit component = yes). If I compile the x64 product configuration, it is still putting my files in Program Files(x86). Now my INSTALLDIR is still set to [ProgramFilesFolder]. This is why I am thinking I am gonna need two different projects for this.
(6) Replies
‎Nov 21, 2008
04:31 PM
It is not recommended to target 32/64 bit applications from a basic msi project. Two projects would be necessary. If a single installer is your requirement, then using an installscript bootstrapper wrapped around a 32 bit msi and a 64 bit msi might do the trick.
‎Nov 23, 2008
04:58 PM
gbaltazar wrote:
It is not recommended to target 32/64 bit applications from a basic msi project. Two projects would be necessary. If a single installer is your requirement, then using an installscript bootstrapper wrapped around a 32 bit msi and a 64 bit msi might do the trick.
Do you mean, it is not recommended to target 32 and 64bit applications within the same basic msi project?
Also, I am not using a single installer, just a single project, that builds to two different installers. Like I said, I am using the Release Flags portion of features with the product configuration build step to determine which features get built with the installer. Thank you for your reply.
‎Dec 10, 2008
05:26 AM
Best practice is having 2 ISM's for 2 Basic MSI's, 1 targeting 32 bit, 1 targeting 64 bit OS.
You may not mix 32 and 64 bit components in the same project...
reg, Henno
You may not mix 32 and 64 bit components in the same project...
reg, Henno
‎Dec 11, 2008
07:34 AM
HennoKeers wrote:
Best practice is having 2 ISM's for 2 Basic MSI's, 1 targeting 32 bit, 1 targeting 64 bit OS.
You may not mix 32 and 64 bit components in the same project...
reg, Henno
Thank you for your reply. I suppose I just needed exactly that since InstallShield tries to support the same project with two different types of processors.
‎Dec 12, 2008
02:53 PM
Most installer designers let you mix target OS platforms on the component level, but with basic MSI doing a validation is absolute mandatory, and then you wind up with a lot of errors.
Also, since the SIS only supports 1 target platform you really are mucking about to mix platforms... its nasty.
reg, Henno
Also, since the SIS only supports 1 target platform you really are mucking about to mix platforms... its nasty.
reg, Henno
