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
- :
- Single .msi for both 32-bit and 64-bit installs?
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
‎Oct 03, 2008
05:28 PM
Single .msi for both 32-bit and 64-bit installs?
I have an existing .msi installer with 32-bit components. This also needs to run in Vista 64-bit and work correctly.
Testing the current installer build on Vista 64-bit reveals that certain registry keys are not being written correctly. The installer .msi writes directly to a couple of registry keys during installation.
HKCR\CLSID\{231980AC-130D-49d6-8997-822E78EA46E5}\etc.
is being written to:
HKCR\Wow6432Node\CLSID\{231980AC-130D-49d6-8997-822E78EA46E5}\etc.
and
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\etc.
is being written to:
HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\etc.
Specifically, the above is for a desktop icon (not a shortcut link). This works okay in Win32 (XP/Vista) but fails in Vista 64.
If I go hack the registry using regedit.exe and put in the correct keys, the desktop icon shows up correctly.
So...
Is there a way for force the registry keys to be written directly to the exact registry keys intended from a 32-bit installer (with all 32-bit components)?
I have tried setting the 64-bit component flag on a component, but get an error when building the installer project:
"Intel64 or AMD64 must be specified in the template of the Summary Stream."
What does this mean? I don't want to mark the entire .msi as 64-bit as it also needs to run in 32-bit windows.
Thanks in advance,
Don Metzler
Testing the current installer build on Vista 64-bit reveals that certain registry keys are not being written correctly. The installer .msi writes directly to a couple of registry keys during installation.
HKCR\CLSID\{231980AC-130D-49d6-8997-822E78EA46E5}\etc.
is being written to:
HKCR\Wow6432Node\CLSID\{231980AC-130D-49d6-8997-822E78EA46E5}\etc.
and
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\etc.
is being written to:
HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\etc.
Specifically, the above is for a desktop icon (not a shortcut link). This works okay in Win32 (XP/Vista) but fails in Vista 64.
If I go hack the registry using regedit.exe and put in the correct keys, the desktop icon shows up correctly.
So...
Is there a way for force the registry keys to be written directly to the exact registry keys intended from a 32-bit installer (with all 32-bit components)?
I have tried setting the 64-bit component flag on a component, but get an error when building the installer project:
"Intel64 or AMD64 must be specified in the template of the Summary Stream."
What does this mean? I don't want to mark the entire .msi as 64-bit as it also needs to run in 32-bit windows.
Thanks in advance,
Don Metzler
(3) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 04, 2008
03:30 PM
You can specify only one processor type for the Template Summary property of an .msi package. Therefore, you can't specify something like Intel and x64 in a single package. A package can have one value or the other, but not both. Although 32-bit installations run on 64-bit machines, they cannot install to 64-bit locations, as you noticed in your test. These are limitations of Windows Installer, as documented in About Windows Installer on 64-Bit Operating Systems on MSDN. Here's a link to a blog post that has more information:
http://blogs.msdn.com/heaths/archive/2008/01/15/different-packages-are-required-for-different-processor-architectures.aspx
Note that you can build two installations (one 32 bit and one 64 bit) from a single project by using release flags and by overriding the Template Summary property for different product configurations in the Releases view.
http://blogs.msdn.com/heaths/archive/2008/01/15/different-packages-are-required-for-different-processor-architectures.aspx
Note that you can build two installations (one 32 bit and one 64 bit) from a single project by using release flags and by overriding the Template Summary property for different product configurations in the Releases view.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 05, 2008
12:26 PM
DebbieL wrote:
You can specify only one processor type for the Template Summary property of an .msi package. Therefore, you can't specify something like Intel and x64 in a single package. A package can have one value or the other, but not both. Although 32-bit installations run on 64-bit machines, they cannot install to 64-bit locations, as you noticed in your test. These are limitations of Windows Installer, as documented in About Windows Installer on 64-Bit Operating Systems on MSDN. Here's a link to a blog post that has more information:
http://blogs.msdn.com/heaths/archive/2008/01/15/different-packages-are-required-for-different-processor-architectures.aspx
Note that you can build two installations (one 32 bit and one 64 bit) from a single project by using release flags and by overriding the Template Summary property for different product configurations in the Releases view.
Thanks for the information. This confirms what I suspected.
Don
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 05, 2008
01:21 PM
This is all true, but if your willing to color outside of the lines and having a unified package is very important to you, there are those who say you can do this:
http://blog.deploymentengineering.com/2008/01/even-developers-are-concerned-about.html
http://blog.deploymentengineering.com/2008/01/even-developers-are-concerned-about.html
![](/skins/images/D60DF682EA37BF37032955CE10F3F0BB/responsive_peak/images/icon_anonymous_message.png)