Click here to Skip to main content
15,907,001 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:

I am using InstallShield 2009, Basic MSI project and need to install some of the files conditionally based on processor architecture type (32-bit or 64-bit). I created two separate components FILES64 and FILES32 which contains necessary files and need to copy the files conditionally on INSTALLDIR.

IF (32-bit) THEN

I tried to select Condition property of the component using Condition dialog. However, I cannot find an installshield property that states 32-bit or 64-bit. Can anyone help here?

Sergey Alexandrovich Kryukov 21-Jun-13 16:30pm    
This is a certain problem, but quite resolvable. Look: there are many complains about InstallShield (which I never used). Microsoft removes its "Setup project" type and template from Visual Studio bundle.
The only fully legitimate install software I can see now is Open-Source Microsoft WiX (compatible with MSBuild and even plugged in VS). I know how to do it all in WiX (which would really need some search or answer). So, if you agree to switch to WiX, which I highly recommend, I'll gladly share the comprehensive information on platform-dependent installation.

It's two-fold: you make it depending on available target instruction set architectures of the product, on architecture of the target machine or both.

[no name] 21-Jun-13 19:20pm    
Thanks a lot for your response, SA! I would certainly be interested in knowing more about Microsoft WiX. Please do share the info.

Please note that below are the two most important requirements for my setup:
1) The install program will need Admin permissions and should be able to make changes to My TARGETDIR folder. During install, I need to provide read/write permissions to the TARGETDIR folder since my app database (SQL CE) will reside there.
2) Need to copy certain files to TARGETDIR based on processor architecture (32-bit or 64-bit).

Sergey Alexandrovich Kryukov 21-Jun-13 22:42pm    
Your both requirements are easily met by WiX. In other setup systems, some things like that would requires custom steps, but in WiX, the predefined actions include such things as setting permissions on any file system object, allowing the installed program to work through Windows Firewall, and a lot more. All actions can be a subject of checks of product's and/or target computer instruction-set architectures (x86, x86-86, Itanium (IE64)).

You have to give me some time to take my WiX project to point out the points you are interested in. I will be very busy whole next week but will try to find some time no sooner than Sunday evening. I cannot spend time to give you general walkthrough on all WiX topics; you can find it all in original documentation. Many delicate moments are not well described, but I gladly help on those I'm familiar with.

[no name] 22-Jun-13 0:43am    
Thanks a lot, SA! I have already googled about WiX, downloaded and read some documentation about it but may take some time to learn and use it for my deployment. I will continue my yoga on WiX but may need some help on specific points. So, any help would greatly be appreciated!
Sergey Alexandrovich Kryukov 22-Jun-13 1:29am    
Exactly. For now, see my first answer, to your first item...

Let me first answer to the first of the two question mentioned in the comments to the question. (Please see all the discussion.)

I recommend using Microsoft open-source WiX because this is a really legitimate product. It meets the requirements for Visual Studio add-on; and its own installer actually installs it on Visual Studio of three latest versions (currently). More importantly, it presents correct interface to MSBuild, which is actually a public multiplatform standard. Even the existing "Setup project" which comes with Visual Studio is not a legitimate MSBuild project type; it is excluded from a bundle as of Visual Studio v.2012.

Please see:[^],[^].

This is the documentation and tutorial:[^],[^].

Now, the first question was about the permission change in some file system object. For example, let's assume you want to set permission of some directory, and make it read/write of all users. The trick is: you have to use explicit <CreateFolder> declaration. Normally, directories and files are only created relative to the top-level target directory (which is selected from a predefined set of legal destinations), and they are created implicitly. The reason you need to use <CreateFolder> node for already declared directory is that it allows the child node <Permission>. This is how a sample declaration could look. In this sample, I assume that the permission is changed in some directory representing "All users" data, which is the very typical case:

<DirectoryRef Id="AppDataLevel3">
    <Component Id="DataFiles" Guid="19DC5B16-B3E1-4e5d-A8B4-BF0FADA6AC5A">
        <File Id="ApplicationFile4" Source="SourceFiles/WiX.Very-specal-file.txt"/>
        <CreateFolder Directory="AppDataLevel2">
            <!-- only top level, down levels inherit -->
            <Permission User="Everyone" GenericAll="yes" />

Here, you should understand that many declaration comes in "original" and "Ref" forms, such as <Directory> and <DirectoryRef> or <Component> and <ComponentRef>, so the Id (see the sample above) refers to some prior <Directory> declaration with the same Id. When you get familiar with declarations of Directories, Files and Components from the original documentation, this should be quite clear to you.

Now, I used certain User and GenericAll attributes to chose the target permission. You can learn what are other options, for example, from… Intellisense. Yes, WiX supports Intellisense when used as a Visual Studio add-on.

You also need to make sure the installation process requests the elevated privileges, because changing permission requires it. For this purpose, you have to specify it on the second topmost level of the installation project, under the <Product> element:
<Product Id="*" ... >

    <Package InstallerVersion="200" InstallPrivileges="elevated" Compressed="yes" ... />
    <Media Id="1" Cabinet="" EmbedCab="yes" />

    <!-- ... -->


Your second question is about the instruction-set architectures. The syntax is very simple and easy to find, but I takes some thinking on how to explain it to avoid the usual confusions. Let me do it a bit later; as I said above, I need more spare time to do it.

This first answer should be enough to get started. About the second part — I promised it…

Share this answer
Now I'm giving the promised answer on the processor instruction-set architecture and the implication of different architectures on installation.

First of all, it's good to know the available architectures and their names, as their naming is confusing. To best of my knowledge, Windows installer is presently applicable to the systems using the following 3 architectures: x86, x86-64 (AMD64) and Itanium (IE64). They are all incompatible, but both 64-bit processors run x86 32-bit processes, and this is supported on Windows via WoW64. Please see:[^],[^],[^],[^],[^].

The most usual 64-bit architecture these days is x86-64, but many call it just 64-bit or x64, but this is not an original 64-bit architecture, which is actually IE64, these days usually known as Itanium. The cheaper and more usual x86-64 architecture was originally developed by AMD (hence "AMD64") as the extension of x86, and later embraced by Intel who preserved its original IE64 for more expensive higher level systems. This all often creates all kinds of confusions.

One of the ways to detect the architecture during runtime using the installation built with WiX is to check up the environment variable PROCESSOR_ARCHITECTURE, so the results will depend on how Windows name those architectures in the correspondent variable. The architectures are known under the following names: "x86", "AMD64" and "IE64".

The MSBuild and Visual Studio terminology is different. The names of the same architectures are "x86", "x64" and "Itanium". And, instead of the term "instruction-set architecture", the term "Platform" is used. We will need to use this information below.

You can identify the system operating during installation runtime using WiX <Condition> element, which can be a child of the element <Component>. Therefore, you discriminant the files to be installed at the level of components. (For other possible elements which can use the child element <Condition>, please see the link below.) It can look like that:
   <Component Id="ApplicationFiles64" Guid="{4A91A21D-FC99-419C-8144-211DE78014C6}">
      <File Id="ApplicationFile1" Source="SourceFiles/Some-x86-file.dll" />
      <Condition> %PROCESSOR_ARCHITECTURE="x86" </Condition>
   <Component Id="ApplicationFiles64" Guid="{E59BB1E9-9B56-4355-BCDC-F03501D326A8}">
      <File Id="ApplicationFile1" Source="SourceFiles/Some-x86-64-file.dll" />
      <Condition> %PROCESSOR_ARCHITECTURE="AMD64" </Condition>
   <Component Id="ApplicationFiles64" Guid="{1AD7798A-BE64-4063-AD31-7F386371A150}">
      <File Id="ApplicationFile1" Source="SourceFiles/Some-IE64-file.dll" />
      <Condition> %PROCESSOR_ARCHITECTURE="IE64" </Condition>

Of course, a component can have any number of files and actions. By the way, don't forget that you should generate the whole unique GUID every time it is required by the syntax.

Please see:[^],[^].

This is not the only approach you can use to approach multiplatform/cross-platform installation. There is a number of reasons when you may want to create different MSI of each platform or combine both approaches. The creation of per-platform MSI is well supported if you use MSBuild and/or Visual Studio. The standard way to support it is to use the standard properties $(Platform) and $(Configuration). In particular, you can have different output directories for all combinations of platforms and combination if you put in a corresponding property definition the path like ..\..\$(Configuration)-$(Platform) (the number of ".." will depends on depth of each project relative to your common output directories. You can also put your WiX project in the same solution as your project. Using this naming/path scheme (or any other scheme based on this idea), you can put each kind of resulting MSI file to the same directory as the product itself, so each MSI would pick up output files of correspondent instruction-set architectures.

But still, sometimes you would need to conditionally include some files from some other sources, or just the files with different names, depending on the architecture. This is very typical when you have to deploy some 3rd-party executable files, such as DLLs. How to do it?

The value of the MSBuild property $(Configuration) is known to the WiX preprocessor. Here is how you use it:
<?if $(var.Platform)="x86" ?>
   <!-- declare something for x86 -->

<?if $(var.Platform)="x64" ?>
   <!-- declare something for x86-64 -->

<?if $(var.Platform)="Itanium" ?>
   <!-- declare something for IE64 (Itanium) -->

You can also use <?else?>.

On the use of WiX preprocessor, please see:[^].

Share this answer
[no name] 24-Jun-13 11:07am    
Appreciate your time and effort in helping me with this and detailed response. thanks a lot. I was able to create a basic setup (without GUI dialogs) and is working fine. I am yet to explore the GUI dialogs display for my setup but XML based setup creation is great and easy. One issue I got so far is the registry keys... I tried to add some registry keys to my setup but could not find the same after install although I opened regedit as admin to verify. I am still 30% into the tutorial and hoping it will solve all my issues with a FREE tool. I will keep you posted...
Sergey Alexandrovich Kryukov 24-Jun-13 11:31am    
You are very welcome.

Working with registry is described, for example, here:

Good luck, call again.
[no name] 26-Jun-13 13:03pm    
So far its been going well. I was able complete my tutorial on WIX and build setup for my product. Its pretty good and easy to learn, since I was once an InstallShield developer which does the same internally.

1) I was able to resolve the registry entry on 64-bit machine as it was going to SysWow6432 node instead of main node under HKLM\Software by just adding attribute 64bit to yes.
2) I was able to add components which will be installed based on 64-bit and 32-bit processor architecture (although haven't tested on other machines yet)
3) was able to add read/write permissions to INSTALLDIR as per your tip above.

Launch conditions and other minor stuffs are pending now and hopefully should be done without any issues.

This is a great tool plus FREE and open source. I would recommend this to others too.

Many Thanks!
- CB
Sergey Alexandrovich Kryukov 26-Jun-13 13:29pm    
I'm really glad that you are getting good with it. I've chosen WiX strategically only recently. Interestingly, do you know what was one of the positive factors? Some very negative feedback from some of the users. I was able to recognize: that was the case when certain kind of people who hate something good and like something bad are indicative. The manual character of setup code actually results in better maintainability.

Ron Beyer 24-Jun-13 13:38pm    
+5, nicely explained.
This is literally the stupidest set of answers I've EVER heard.
Q: I'm using InstallShield 2009...….
A: Well, let's gloss over that and I'll give you answers for WiX instead.

It's as stupid as, someone asking for help with FruityLoops on PC and them answering with, "Ah, but you can do it like this with Logic Pro on a Mac".


However, just to help you out with your InstallShield 2009 problem, in the component itself you can specify an architecture type. Remember, this is a component, not a feature attribute.
Share this answer
OriginalGriff 1-Jul-19 11:29am    
While I applaud your urge to help people, it's a good idea to stick to new questions, rather than 6 year old ones. After that amount of time, it's unlikely that the original poster is at all interested in the problem any more!
Answering old questions can be seen as rep-point hunting, which is a form of site abuse. The more trigger happy amongst us will start the process of banning you from the site if you aren't careful. Stick to new questions and you'll be fine.
CHill60 2-Jul-19 3:47am    
You may think they are stupid but clearly the OP thought they were very useful as did other members. OG has mentioned rep-point hunting being seen as a form of site abuse, but so is making disparaging comments about other members. You will see many solutions advising posters to reconsider their tool of choice (especially if they are using VB6) - it's not invalid advice.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900