Installing a New Component in a Minor Upgrade in InstallShield

I have created a lot of minor upgrades before, but recently I had a problem that I could not figure out. Remember that in a Minor Upgrade, the Product Version and Package Code both change.

The Minor Upgrade I was creating installed a new component and file into a new folder. All other components in the original install were still there, and the Component Codes were the same. However, no matter what I did, the new component was not being installed.

I read some posts in the InstallShield community forum and found one that was particularly interesting. It said that you could force the installation of a new component in a Minor Upgrade by setting the ADDLOCAL property. However, I could not find any detailed information on how to do this. I eventually abandoned that idea in favor of something else.

I read on MSDN that in a Minor Upgrade, you can create a new child feature of an existing feature and require that it be installed. You do this by setting the msidbFeatureAttributesFollowParent and msidbFeatureAttributesUIDisallowAbsent bits of the child feature’s attribute in the Feature table. So I created a new child feature of the existing feature, associated the new component with that feature, and set those bits in the Feature Table. That worked.

Hopefully, this will help someone in the future.

The article on MSDN is about Product Codes, but also has information pertaining to Minor Upgrdes. Here’s the link:

Changing the Product Code

Update 07/27/2010: This change only worked for the first two hours I was testing it. I actually found out that if you create a new child feature and add a new component to that, the new component will not be installed. I’m not sure why it worked at first, but I had to come up with a new solution. More on that later.

In InstallShield development, I find there are a lot of tasks I do over and over again. Since, I don’t want to figure them out each time, I like to write them down.

You can call this making notes, or call it Standard Operating Procedures (SOP), but I find it saves me a lot of time because I don’t have to reinvent the wheel each time. I’ll give you an example of what I’m talking about.

Suppose I find myself creating a custom type of release where it is like a CD-ROM, but the installation is cached on the local machine in order for use during advertised installs (install-on-demand). Here are the steps I would perform in the Release Wizard each time I do it:


     Product Configuration
          PROJECT_ASSISTANT
     Specify a Release
          Custom_CdRom
     Filtering Settings
          Default
     Setup Languages
          Default
     Media Type
          Web
     Web Type
          One Executable
     One-Click Install
          Default
     Setup Launcher
          Select Include MSI Engine
          Select Suppress warning
          MSI Engine Version 3.1
          Select Delay engine reboot
     Windows Installer Location
          Download engine from the Web
     Local Machine
          Select Cache installation on local machine
          [AppDataFolder]Wavepoint Studios\Mega View
     Digital Signature
          Certificate URL
               http:/     /www.WavepointStudios.net
     Digital certificate
          \wavepointstudios.pfx
     Private key file
          \wavepointstudios.pvk
     Certificate password
     password12345
     Digital Signature Options
          Select Sign Windows Installer Package
          Select Sign Setup.exe
          Select Sign files in package
               [INSTALLDIR]Mega View.exe
     Password & Copyright
          Default
     .NET Framework
          Unselect Include or set up .NET Frameworks
     Advanced Settings
          Default
     Summary
          Finish


This idea is just a suggestion. It’s something I use all the time and it saves me a lot of time.

Try it out.

I received an interesting email today from someone who wanted to know if there was a definitive way of updating installations when a new version of InstallShield is released. He remarked that there are always new redistributables (prerequisites, merge modules, and objects) in each new InstallShield version, and he frequently has trouble updating the company’s installers with these new redistributables. The question again, “Is there a definitive guide to doing this?”

The answer is no. Even with a lot of InstallShield experience, I have to go through the same process as everyone else. Here is the sequence of events most of us have to go through:

1. A new version of InstallShield is released. With it are new redistributables.
2. We need to update each existing installation project to the new InstallShield version. This is usually taken care of by opening the existing installation in the new version, with InstallShield automatically upgrading the project.
3. If the software being installed has been upgraded to work with new redistributables (since the last release), the old redistributables will need to be unselected, and the new ones selected.
4. Since we may not be familiar with what is installed in the new versions of the redistributables we have selected, we must play it safe and go to Microsoft.com and see what’s included in each one. For example, if we are now including Microsoft .NET Framework 3.5 SP1, we will learn that it installs practically everything Microsoft needed to put in previous versions of redistributables.
5. We build the installation and pray to the Windows Gods that there will be no errors.
6. We test the installation on all Windows platforms and configurations applicable to our software, making sure that it actually works with these new redistributables.
7. We get raised, praised, or fired, depending on the kind of job we did.

That seems to be the process I go through every single time, and to date, I’ve not found a way around it. If you know a better way, or if you have something to add, I would be happy to hear about it. Just leave a comment.

I always thought both Basic MSI and InstallScript MSI installations could pass Windows Logo Certification since they both use the Windows Installer. In doing some research on the InstallShield forum, I found differing opinions, so I was puzzled. However, I eventually found a post which set the record straight.

The specific reference to passing logo certification is on page 2. Here is the link to that page:

Need answer from InstallShield staff please regarding Windows Vista Logo Program Test

While working on a pure InstallScript installation, I tried all of the built-in path selection dialogs looking for one that would fit my requirements.

What I needed was a dialog that would allow the user to select a new folder, whether it was on the hard drive or on the CD/DVD-ROM drive. I was writing an installation for a mapping product where the user could read the map libraries from the DVD-ROM or from the hard drive. If they wanted to read from the hard drive, the libraries would be coped there during installation.

I looked at the following built-in functions:

• AskDestPath()
• AskPath()
• SdAskDestPath()
• SdSelectFolder()
• SelectDir()

It turns out that none of these would work. The reason is they call SelectDir(), and that function will not allow you to choose a CD/DVD-ROM drive as a destination. These functions were probably written with the idea that the user would only use them to select a destination path for the installation. If that’s the case, then it all makes sense. But that wouldn’t work for me.

I created a .NET Class Library and called it from the script. In the library, I used the .NET FolderBrowserDialog() function with the ShowNewFolderButton property set to TRUE, so the user could create a folder if he wished. It worked like a charm.

I am documenting this in case someone needs similar functionality in a pure InstallScript project. There is no need for you to look for a built-in InstallShield function, when there isn’t one.