64 bit vs 32 bit Installation Support?

[MWieder]

We have an applicaiton that needs to be able to be installed either on a 32 bit or a 64 bit platform. We want to use a single Installshield source for this, but have no issue creating two seperate outputs if that's what is needed.

Is there a tutorial to help us through the process or would someone be kind enough to outline the steps so we can take our current 32-bit only Installshield file and have it produce 1 or 2 outputs that work on both 32 bit and 64 bit systems?

Specifically, I am concerned with Registry keys as we write configuration values to HLMK/SOFTWARE and the 64 bit registry looks different from the 32 bit one.

Thanks in advance for your time.

[Christoph]

I have actually the same question.

Is it possible to generate from one project a 32-bit installer package and a 64-bit installer package(build automation-wise...)?

[dan_galender]

While there is almost never only one way to do something, here is a potential solution to consider. You can try the following (I hope I remember all of the steps ;)):

Create a "hybrid" project:
[LIST=1]

• Make it a 32 bit project (using the default Template Summay Architecture "Intel;1033", 1033 for English) with two sets of features and two sets of components (one each for 32 and 64 bit). They are mirror images of each other, with the 32 bit components associated with the 32 bit features and the 64 bit components associated with the 64 bit features.
  
• Set the components' 64 bit property to "Yes" for the 64 bit components.
  
• Set the Display Name and Description properties of the mirrored features to the same string table entries.
  
• Set both sets of features' Release Flag properties to either "32Bit" or "64Bit", as appropriate.
  
• Create two Releases (one for 32 bit and one for 64 bit) filtering out the undesired freatures based on the features' Release Flags.
  
• For any actions that you only want to run for one of the platforms, use the condition VersionNT64--it will be true for any 64 bit platform and false for 32 bit platforms.
  .
  

Create a small VBScript program that uses the Automation Interface to do the following:
[LIST=1]

Makes a copy of the 32 bit project with a different name (like append "64" to the end of the filename). This newly created project will be the 64 bit project.

Opens the newly created (64 bit) project.

Sets 64 bit project-wide properties (ProductName [if desired, like to append " (x64)"], ProductCode [if you want a different one], and INSTALLDIR [change references to ProgramFilesFolder to ProgramFiles64Folder]).

Changes the Template Summary Architecture property for 64 bit (for example, "x64;1033").

Saves the project.

Closes the project.
.

As needed, make all project modifications to the 32 bit project (realizing that for any newly created components, you'll need to create two and changes to the feature/component tree will need to be done in both trees). But changes to custom actions and sequences will only be done in one place :).
.

Build your releases using the Command Line or Standalone Build tools:
[LIST=1]

Run the VBScript to create the latest and greatest 64 bit project from the current 32 bit project.

Build the 32 bit Release from the 32 bit project.

Build the 64 bit Release from the 64 bit project.
.


And Bob's your uncle.

[cbarlow]

What's the best way to set INSTALLDIR to ProgramFiles64Folder for the 64-bit package and just ProgramFilesFolder for the 32-bit package? I can do this with a custom action that checks on the VersionNT64 property, but this makes it so that the 32-bit package defaults to the C:\Program Files directory when installing on 64-bit machines instead of C:\Program Files (x86). What I really want to do is check on the Release Flag. Is there a way to use Release Flags in custom actions?

Thanks!

Clark

[cbarlow]

I got it. You have a good description of this in your help. I had a typo in my release flag.

Thanks

[Christoph]

Thanks Dan!

Very usefull information... 🙂

[Christoph]

@Dan,

one remark...
Why should you define 2 sets of features(32 -and 64bit).
If you define your 2 sets of components(32bit and 64bit) under the same feature, it filters out the unneeded components automatically during the build... or not?

What I want to say is that, disregard the fact that it is cleaner, it is not needed to create two sets of features for a 'hybrid' package...

Or am I missing something?? :confused:

[dan_galender]

Christoph wrote:
If you define your 2 sets of components(32bit and 64bit) under the same feature, it filters out the unneeded components automatically during the build... or not?

No. Features can contain 32-bit and/or 64-bit components. Both 32-bit and 64-bit components can be installed on 64-bit systems, but 64-bit components will generate install-time errors if you try to install them on 32-bit systems. Using Release Flags will filter out the undesired components (and features) from the builds.

It was pointed out to me, however, that the Product Name, Product Code, and Template Summay can all be specified on the Product Configuration settings. Combine that with a custom action that sets INSTALLDIR to a sub-folder of ProgramFiles64Folder with a condition of VersionNT64, and it appears that the VBScript program wouldn't really be necessary after all, just build both (32-bit and 64-bit) releases from the same project.

[noisor]

Hi Dan,

thanks for this descirption.
Just wondering what you mean with mirroring of features/components. :confused:
My question in detail is:
I have a big setup using many features and components and I need only a special part for the 64 Bit release.
Do I have to duplicate all features and components or can include 32 Bit features into the 64 Bit release with the additional 64 Bit feature?

Thank you in advance!

Regards
nois

[dan_galender]

What I mean is, for any feature that you want to have either 32-bit specific components or 64-bit components, make identical (what I was calling "mirrored") features (with sub-features, if necessary)--one for 32-bit and one for 64-bit--that have either all 32-bit components or 64-bit components associated with them, respectively. By using Release Flags, you can then perform architecture-specific builds--32-bit or 64-bit--and eliminate from each build the undesired features and components (so that the 32-bit build contains no 64-bit features and components and the 32-bit build contains no 64-bit features and components).

[noisor]

Hi Dan,

thats exactly how I solved it yesterday myself - and it works fine :cool:
Thank you for your help!

Regards
Thomas

[prashantlade]

Hi Dan,

Looks like you have done plenty of research on 64 bit stuff.
I just posted a new thread with title "64 bit MSI upgrade" Is it possible for you to answer my question?

I have also pasted my post here..

-----------
I have created a basic MSI project to install our product. It has got some file deployment, registry changes and printer driver installations. Here is the catch.

Some of my product files are 32 bit binaries and the printer driver stuff is 64 bit. My product will be installed in Program files (x86) as it's not native 64 bit application. I managed to do it's installation and repair successfully. However, not it's time to write upgrade for newer version. The upgrade works fine for the 32 bit project but when I make same changes in 64 bit project, it doesn't work. It does deploy all the files correctly but it fails to install the printers. Printer driver installation is achieved through a C++ DLL functions. I load the dll and call the functions.

I am aware of the registry/file redirection and somehow I feel that I have messed it up somewhere. Can anyone provide me pointers/help docs/forum links which will help me in resolving this?

I have created a major upgrade which removes old product and installs the fresh product. On windows XP, as soon as I run the new installer package, it throws an error for one of the printer driver files deployed in system32 folder. The error code is 2 and it shows that the file not found. When I check the path, I see the file there. Why is that error? I copied the same file in SysWow64 folder, this error goes away but the printers are not installed. On windows 7 platform, this error is not displayed and the installation goes ahead but fails to install the printers. I think the root cause is incorrect redirection. How can I achieve redirection for Basic MSI projects containing partially 64 bit components?

This forum is the only hope foe me...please shoot more questions if you would like to know more...

Regards
Prashant Lade

[ZygoCorp]

In our application many components are common to our 32 and 64 bit installations. For those that are not, we created a 32bit component and a 64bit component. Associate both versions to the appropriate features. Create 2 releases in the project, one for a 32bit install, one for a 64bit install. Use the release wizard to exclude the inappropriate components. When we build an installer, we just have to build both releases. We have had no issues with either installer.

[loralynne]

Hi Clark,

I'm trying to accomplish the same thing with regard to setting INSTALLDIR to ProgramFiles64Folder for the 64-bit package such that when running the 32-bit package on a 64-bit machine, the default is still Program Files (x86). I thought of using the Release Flag also, but that doesn't seem to be possible. Can you please tell me how you resolved this issue?

Thanks,
Lora

[dan_galender]

loralynne wrote:
Hi Clark,

I'm trying to accomplish the same thing with regard to setting INSTALLDIR to ProgramFiles64Folder for the 64-bit package such that when running the 32-bit package on a 64-bit machine, the default is still Program Files (x86). I thought of using the Release Flag also, but that doesn't seem to be possible. Can you please tell me how you resolved this issue?

Thanks,
Lora

You could have SetDirectory Custom Action (with a condition of VersionNT64) that changes INSTALLDIR from [ProgramFilesFolder]... to [ProgramFiles64Folder]....

[loralynne]

Thanks for your response, Dan. That's actually exactly what I have, and I believe Clark had this same problem also. This won't work since a 32-bit installer run on a 64-bit machine will change INSTALLDIR to ProgramFiles64Folder, which is not I want. I want this custom action to be executed only for my 64-bit installer, so I need to condition this CA as such. For my 32-bit Release, I have a release flag called 32bit and for my 64-bit Release, I have a release flag called 64bit. I was hoping I could use the 64bit release flag for this CA.

[dan_galender]

Not sure I understand the behavior you're seeing. Are your components defined as 32-bit components on 32 bit systems and defined as 64-bit components on 64-bit systems?

[loralynne]

I have both 32-bit components and 64-bit components in my project. My 64-bit release includes both the 32-bit components and the 64-bit components. I have a CA that sets the INSTALLDIR to ProgramFiles64Folder, and it has the condition VersionNT64. I build my 32-bit release, and it runs as expected on a 32-bit machine. When I run it on a 64-bit machine, it executes the CA that sets INSTALLDIR to ProgramFiles64Folder since the condition VersionNT64 is met. However, I don't want this CA to be executed when I run my 32-bit installer on a 64-bit machine. I only want it to be executed when I run my 64-bit installer.

[DebbieL]

Perhaps try what's mentioned in this help topic:
Conditionally Launching Custom Actions Based on Release Flags

[loralynne]

That's exactly what I'm looking for. Thanks so much, Debbie.

[Kovalenko]

Hi,

I have come to the following solution as DanGalender. In the result I have two Product Configurations. One configuration is x86 and the other is x64 (set via Template Summary). Each of them has two Releases - Debug and Release.

My problem: when you build the setup project, only Default Product Configuration is built. To build the other configuration I need to set it default. And I cannot figure out how I can to it from a command line. Setup project is built by "devenv 'Setup.isproj' \Rebuild Release". Do I need to create a new Solution configuration?