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.

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.

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.

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

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.

The Windows Installer uses a three-part version number. As a result, all version numbers must conform to the following format:

          major.minor.build

An example version using this format would be 2.10.015.

That’s nice you say, “But all the version numbers in my company are of the format, 4.50.100.451.”

Okay, but the Windows Installer will ignore the last part (the .451). Now, you can use a four part version number in Basic MSI and InstallScript MSI projects in InstallShield, but the Windows Installer will still ignore the fourth part.

I can’t explain why Microsoft came up with this format. At least 80% of the people I talk to use a four-part version number in their company. And they are all just as upset about this as you are. So, to get you over being upset, here’s a little humor.

The Windows Installer has it’s own internal version number that signifies what version it is, and I bet you can’t guess what the format is:

          major.minor.build.update

We see that Microsoft wanted the internal version number of the Windows Installer to have four parts, but the public can only use version numbers with three parts.

Makes perfect sense to me.

I downloaded the trial version of InstallShield Premier, installed it, and exported the Swedish string table. I then went back to my copy of InstallShield Professional and imported the Swedish string table before I did any work on the installer. After importing, I did all the work the client required.

In this installer, I didn’t create any English strings, so my theory was that when I gave the finished installation to the client, all he would have to do was rebuild the project on his end, and everything would be fine. Well, that’s exactly what happened.

The only caveat in doing this technique is that if you create any English strings or any English custom dialogs, then the client will have to translate those strings from his location. In my installation, I didn’t have to do any of those things, so it made it easy for the client.

Now, what was the difficulty in this whole project? The only difficulty was that all the dialogs were in Swedish, so I sometimes had to look back at the actual dialog name, to understand what was really going on. But it all worked out.

This technique will work for anyone needing to create an installation that is in a language different from the language of the InstallShield copy they own.

Go to the Direct Editor view in the InstallShield IDE and select the File table. Here is a screenshot of the file table from one of my own projects:





The FileName column holds the name of the files being copied to the target system. The Component column holds the name of the Component that each file belongs to. For this discussion, we are interested in the Sequence column.

Notice that InstallShield places 1s in this column by default. But if you have a file that you want copied to the target system first, just leave that with a Sequence of 1, and change everything else to a greater number. Files are copied to the target system with the lowest sequence numbers first, highest sequence numbers last. In our example, let’s say we want Mega View.exe copied first, so we leave that as a 1. All other files should be changed to something greater. Here we are using 10.

Now, what’s the downside to this strategy? It’s that everytime you add new files to your project, you will have to go to the File table and set the Sequence for those files.

I entertained doing this for a client project, so I thought I would pass it on.

The overwhelming majority of people prefer to use the Basic MSI project. But if you are new to installation development, you may find that the Basic MSI project has a steeper learning curve. I have written posts on this. Just search this website.

When Microsoft created the Windows Installer, they realized it would not provide all the functionality to cover every conceivable Windows installation scenario that people would come up with. The possibilities are just too endless. However, even writing custom actions in a Basic MSI project will not always accomplish what you want. So, why would you ever want to use the InstallScript MSI project?

You should know that to some installation developers, the InstallScript MSI project type is a joke. These people can not fathom why you would use such a thing. Especially, when it is seen as a hybrid of the Basic MSI and InstallScript project types. However, the InstallScript MSI project uses the Windows Installer, the InstallScript project does not.

Other developers feel the InstallScript MSI project is the weakest type of project that InstallShield offers. However, there are some very appropriate times to use it.

If your boss or client is requesting something out of the ordinary, it may not be possible to accomplish it in a Basic MSI project. Generally, this has to do when they want control over every aspect of the installation. I’ll give you a perfect example.

Let’s say your boss wants a user to be able to click the Uninstall button in the Add/Remove Programs dialog and then bring up a Custom dialog box which presents two options. Uninstall option 1 and uninstall option 2. Let’s say option 1 drops a SQL Server database and option 2 does not. The user chooses an option, clicks the Next button, it goes to the ReadyToRemove dialog, the user clicks Remove, and the program is uninstalled according to the option they selected.

Now, you can not do this in a Basic MSI project. Why? Because when you click the Uninstall button in Add/Remove Programs, the User Interface sequence is skipped, and just the Execute sequence is performed. So, you can’t do it in Basic MSI. If you want this degree of customization, then you should consider the InstallScript MSI project.

There are other examples where an InstallScript MSI project makes more sense, and it’s generally when you want a higher level of customization than Basic MSI is able to provide. And that’s when it’s perfectly acceptable to use InstallScript MSI.

Don’t let anyone make you feel bad for using it.

Here’s the message:

“The installation of Microsoft SQL Server 2008 Express SP1 (x86) appears to have failed. Do you want to continue the installation?”

Here is a screencap of the error:

So, what do you do? Well, after a day’s worth of investigation I found out that the error was caused by the wrong combination of command line options on the Application to Run tab of the Prerequisite Editor. When I corrected the options, the problem went away

I’m not going to give you specific options because the combinations are endless. In addition, the main point I want to make is that this can not just happen with SQL Server 2008 Express, it can happen with any prerequisite you have edited.

One test you can do is create a batch file with the name of the executable and the corresponding command line options. If you get it working from the command line, then you can use those same options in the Prerequisite.

Try this the next time you run into trouble.