InstallShield: One basic tip for using Install Level and SetupType dialog to control features in Custom Setup

Working with software packaging, just soon or late, you will ask the question how to show/hide or select/deselect a feature during setup. The larger your packaging projects are, the sooner the question comes. Sometimes, it becomes very tricky to control the features during setup and one little bug may cost you a couple of good days to trace to the root. It will be more complicated if you're working on projects created  and designed by many other people before you. This post will show you a small tip to deal with custom setup in two scenarios: fresh installation and major upgrade.  

(Source: here)

First of all, to get a clear idea what this post is about in case you got lost with my introduction above, I will give a brief explanation here. We will just talk about Custom setup which is showed in the picture above. As you can see, there may be three feature options:

- a feature with a red X sign: it means the feature is visible to end-user but it's not selected to install by default. End-users need to explicitly select it they want to use it on their local machine (target machine). Usually, these features are optional. Packaged software still functions well without this feature. 

- a feature with a hard drive icon: it means the feature is visible and available by default installation level. These features are usually compulsory, without them, the packaged software may not function properly. If end-users don't want to install these features on their local system, they need to explicitly deselect them.

- hidden features: these features may be available inside packaging software but not available for end-users in some contexts. Why do people design features and then they don't want them to be installed on target machine? There are some possibilities.
i) A feature was designed long ago and  is getting obsolete now. Therefore, the packaging engineer just wants to exclude it out of the package without changing the packaging environment much. (or the company may need the feature back later as well :-D, you know what I mean, it's safer to backup then remove completely)

ii) Some features are designated for 32bit platform and some others are for 64bit platform. Absolutely, you don't want to show features of 32bit platform on 64bit target system and the other way around. 

There are some possible ways to achieve all those settings above for features like using feature settings (install level and display properties), using installscript functions, using SetupType dialog. I will come across two of them in this post. 

What is Install Level? You may want to glance quickly on these two links: Microsoft MSDN and Flexera Community Forum. Technically, every installation project needs to define its default install level. Features will be installed or not depends on how feature install level is set in feature settings compared with the project default install level. With InstallShield, the default install level for a new project is 100. You can change this number anytime as long as you understand what you're doing and how it affects to your packaging software. It's called INSTALLLEVEL under Property Manager. When a feature install level is set to a value smaller than 100, the feature will be selected in custom setup dialog. When a feature install level is set to larger than 100, the feature will be unselected in custom setup. Display property in feature settings will control if a feature should be visible or invisible in custom setup. 

If your installation software never shows Cusom setup dialog to end-users or never needs to handle major upgrade from previous installation, understanding about Install Level above is enough to control all of your features. 

However, in my case, we need to handle much more than that. We have some features which used to be installed by default on all target systems; and after that, we've moved them to context installation depending on the target processor (32bit or 64bit). Basically, those features were not removed completely, just changed the condition from all systems to 32bit systems only. In the meantime, we also created similar features to handle 64bit platform. The old and new features are doing the same job, but they're excluding each other. We still handle major upgrade for all those features (both 32bit and 64bit platform) if it's required.  The tricky part is, if both features of 32bit and 64bit platform were installed on target machine previously, we just allow upgrading and running with 64bit feature in major upgrade. We need to disallow and discontinue 32bit feature in this case.

Obviously, setting up Install Level only (from feature settings on GUI) won't help overcome the situation above. Analyzing installation log won’t help much. In my case, I've set my feature install level to 200 against the default install level 100. With that setting, in major upgrade, the feature is supposed to be removed and action should be null. In real, here is what showed in my log: 

Action start 12:13:57: InstallValidate.

MSI (s) (04:0C) [12:13:57:354]: PROPERTY CHANGE: Deleting MsiRestartManagerSessionKey property. Its current value is '7301106bfb7a984bb7deb9ee9d4ef53a'.

MSI (s) (04:0C) [12:13:57:354]: Feature: Database; Installed: Absent;   Request: Local;   Action: Local

With that line, you know that the feature is still installed regardless to the condition you set on the top of feature settings. The bad part is the log won’t tell you the reason why.

The solution here is that, I need to move on with the second level: control features in SetupType dialog before showing them on CustomSetup dialog. No matter you show Custom Setup dialog or not, this step is still required. I lost my whole day for this issue just because my current project doesn't show CustomSetup dialog and by default I thought there was nothing to do with the dialog settings. If this sounds like your situation, here is what you should do. 

- from SetupType dialog,
- go to Behavior -> Next button event
- add one more record to control your feature

Here is an example.

You can discover a lot of settings from those drop-down boxes on the right side. Personally, I think those settings are very very powerful. You can use them for many purposes, not only add and remove features limited in the context of this post. 

With basic understanding about available settings given by InstallShield (or Windows Installer in general) as written above, I can walk through many tough situations which may cost me many days to troubleshooting. It's extremely hard to form a question and post to community forum for help because your environment and setup are usually unique. The worst of it is that you may have to wait very long and you don't really receive much useful answers (if you're lucky enough to have some answers). It's always good to know one step in advance.   

Finally, to end this post, there is a small note. Remember that whatever you can set for features on InstallShield GUI, you are also able to do the same with installscript coding. If you are proud of coding for everything in your packaging software, you can still do that. Just write a function to control visibility and availability for all features and call it before SetupType and CustomSetup dialogs are executed. I've tried this and it worked beautifully as well. Reading about MsiSetFeatureState and MsiSetFeatureAttributes in help manual is a good start.