Let’s look at few examples.

1) Set a Component’s Permanent and Never Overwrite properties to Yes. When you do this, the files in the component will not be overwritten or removed under any scenario. Okay, you can remove them manually, but I’m talking about them not being removed in an installation/uninstallation scenario.

2) Copy Files to Temporary Folder at Beginning of an Install, Do Main Install, Then Copy Files Back at End of the Install. This is good if you are doing an upgrade. Or you are doing the non-best practice of installing a new version over an old version (and not using an upgrade installation).

3) Rename Files to Another Name. This works because the renamed files will not have been installed in the initial installation, therefore they won’t be uninstalled.

4) Copy Files to Another Name. This works because the copied files will not have been installed in the initial installation, therefore they won’t be uninstalled.

5) Do a Minor Upgrade Where the Only Thing Changed is the Component’s Permanent and Never Overwrite Properties set to Yes. This idea was suggested to me one time by InstallShield technical support. I have to say I had never thought of this and it is a creative way of solving the problem. If you don’t follow the logic, let’s say you installed a product that has a couple of files that are important to the product. Perhaps they contain user settings. Time passes and you wish you had set the component’s properties for these files to Permanent and Never Overwrite in the original installation. You can then create a minor upgrade where the only thing changed is that component’s properties being set to Permanent and Never Overwrite.

Those are some suggestions for you to use next time you are faced with this situation.

Here is a screenshot of the error that was displayed:

1904 Error when installing SAP Crystal Reports 2011 for .NET Framework 4.0

The screenshot above shows the error that is referring to missing dependencies of crtslv.dll, which is installed by the Crystal Reports merge module.

To find the missing dependencies, I opened the InstallShield Basic MSI project I was working on and went to the Dependency Scanners view. Here is a screenshot of that view:

InstallShield’s Dependency Scanners view

Although there are three scanners available, I selected the Perform Static Scanning wizard, it came up, I ran it and the screenshot below shows the results:

Dependency Scanner results

The screenshot above shows a few of the results that the scanner found. There was actually a long list. You just select the ones you want to include and InstallShield will add them to your project.

I added the redistributables it recommended, rebuilt the project and tested again. Same result, same error.

My next step was to use Microsoft’s Dependency Walker tool. If you do a search for this on the web, you will find the link and be able to download it. You will get a zip file with three files. You just copy them to a folder and then run the tool.

After running Dependency Walker, I browsed to crtslv.dll and selected it. The tool then found all the missing dependencies. The following screenshot shows the results of the scan:

Microsoft’s Dependency Walker

The above screenshot shows the results of the scan for crtslv.dll. You can see it lists four missing DLLs:

• ATL80.DLL
• MSVCR80.DLL
• GPSVC.DLL
• IESHIMS.DLL

I passed this information on to the client and they addressed it on their end. This was something they needed to take care of during the building of their product.

Bottom Line: These two tools are slightly different from each other in how they work and in the information they provide to you. I can’t say one is better than the other. That’s why I use them both. Perhaps you will too.

Therefore, in this post, I will talk about how to do just that.

Generally, people want a small footprint installation file because their product is downloadable from their company’s website. There are other reasons, but they are not important. How to do it is what’s important.

To get a small installer file, you need to look at two things, redistributables and compression. Let’s look at each of these.

When you create a release in the Release Wizard, or manually in the Releases view, you can either choose to Compress all files or Leave files uncompressed and separate from the installation package. Check out the screenshot below.

Release Configuration page in the Release Wizard

The screenshot above shows where I have selected the SINGLE_EXE_IMAGE release in the Releases View, and I have the Release Wizard open to the Release Configuration page. Obviously, since this is a Single Exe release, I have chosen Compress all Files. That’s the easy part of getting a small installer file.

The redistributables aspect is little more complicated in that it involves more possibilities and choices. First, let’s revisit the Redistributables view.

In the Redistributables view of an InstallShield project, there is a collection of prerequisites, merge modules and objects. One or more can be added to your project. In fact, you can have any combination of prerequisites, merge modules and objects.

Prerequisites can be installed by the Setup.exe bootstrapper or can be installed after feature selection, during the main installation.

Merge Modules are generally installed during the main installation. But I swear I have sometimes seen them being installed while the Preparing to Install dialog is displayed.

InstallShield Objects are always installed during the main installation.

Have a look at the next screenshot.

Redistributables view in an InstallShield project

The screenshot above shows the Redistributables view and as you can see, there are a variety of Prerequisites, Merge Modules and Objects available.

With Merge Modules and Objects added to a Single Exe release (Setup.exe), you don’t have a choice. These redistributables will be compressed into your single Setup.exe file. However, with Prerequisites, you do have a choice.

Take a look at the screenshot below:

Prerequisites come in two types

The .NET 4.0 prerequisite I have marked with a 1 is a full prerequisite. That means the entire .NET Framework 4.0 prerequisite is going to be compressed into your Single Exe file. Of course, this will result in a bigger file.

The .NET 4.0 prerequisite I have marked with a 2 is a web download prerequisite. That means .NET 4.0 won’t be compressed into your Single Exe, but instead downloaded from the Microsoft website during your product’s installation. When you choose web download prerequisites, the end result is a much smaller installation file.

At this point, you may be thinking that you will just always choose the web download version of a prerequisite. The problem is that not all prerequisites have both full and web download versions. So, what do you do? Well, don’t give up yet. There is still hope.

Check out the screenshot below.

InstallShield Prerequisites Location property

In the screenshot above, I am back in the Releases view, I have again selected the Single Exe release and have clicked the Setup.exe tab. Now, look at the InstallShield Prerequisites Location property. I have set it to Download From The Web.

When you use Download From the Web, all of the InstallShield prerequisite files included in your project will be downloaded from the web, if it is necessary. Obviously, if a prerequisite is already installed on a user’s machine, it won’t be installed again.

To continue, each individual prerequisite will be downloaded from the URL specified in the InstallShield prerequisite (.prq) file for each prerequisite. This option overrides the locations specified in the Redistributables view for each InstallShield prerequisite’s properties.

You should now have all the information you need to produce the smallest Setup.exe file possible. To summarize, here’s what you need to do:

1. Create a Single Exe release that includes Setup.exe
2. Choose Compress all files on the Release Configuration page of the Release Wizard.
3. When possible, choose Prerequisites instead of Merge Modules or Objects.
4. In the Releases view, select your Single Exe release, click the Setup.exe tab and set the InstallShield Prerequisites Location property to Download From The Web.

Now you know what to do in order to get the smallest installation file possible.

It is possible to change the strings in the ‘Preparing to Install…’ dialog that is displayed by the Setup.exe bootstrapper. Now, this article pertains to both the Basic MSI and InstallScript MSI projects.

Here is a screenshot of the dialog:

The Preparing to Install dialog displayed by the Setup.exe bootstrapper

If you look in your installation project, you will find that there are no InstallScript or MSI settings backup up this dialog.

The strings that appear in the dialog are contained in the string resource files that are created in the release’s Disk1 folder. A separate string resource file is created for each language that your installation supports. The name of each resource file is based on the hexadecimal representation of the numerical language ID for a given language. For example, a project that supports English has a language ID of 1033 decimal. Therefore, a file named 0×0409.ini (0409 hex is 1033 decimal) will be created in that folder.

Here is a screenshot of the Disk1 folder in an English language Basic MSI project:

The Disk1 folder in an English language Basic MSI project

I have circled the language file you should modify if your project is in English.

Here’s a link to the original Knowledge Base article:

Q106278: INFO: Modifying Text In ‘Preparing To Install…’ Dialog

That’s because it’s not there. You have to go to the Release Wizard.

Here is a screenshot of the .NET Framework panel in the Release Wizard:

Add the .NET Framework 2.0 redistributable from the Release Wizard

Here, I have selected to include the 2.0 version of the framework, it will be extracted from Setup.exe (this example is a Single Exe release), and we are delaying reboot until after the installation completes.

Next time, you’ll know where to find it.

First off, the latest version of the Windows Installer is 5.0 and if you look in the Redistributables view of an InstallShield project, you will not find it anywhere. Moreover, you can not find any version of the Windows Installer that is marked for use with Windows 7. Why is that?

It’s because both Windows 7 and Windows Server 2008 R2 include Windows Installer 5.0. So, when you create an installation that works on Windows 7, you don’t need the Windows Installer. It’s already there.

So, relax man. Take a deep breath.

Now, if you read this blog a lot, you know I write a lot of InstallScript custom actions. The main reason is I’m lazy and if I can do what I need to do in InstallShield, I will. However, this might have been a little easier in a Managed Code Custom Action written in C# or Visual Basic.NET. It’s debatable.

Here is the actual InstallScript code that I used. It’s nothing revolutionary. The reason I am sharing it is that I want you to notice how I am building the connection string. SQL Server connection strings are different in 32-bit than they are in 64-bit. I’m not a SQL Server expert, but I have learned that.

Here’s the code.

Using an InstallScript custom action to check if a database exists

You will notice in the code that there are several MessageBox calls. These are just for debugging purposes.

Also notice the WsGetProperty calls. This is just my version of the MsiGetProperty function. InstallShield changed how that function works in the 2012 version, so I created my own function to account for that.

Hope this helps.

First off, let’s refresh our memory on how we uninstall a software product. To do this, we go to Add/Remove Programs (Programs and Features in later Windows versions), select the product from the list, and this is what we see:

Add/Remove Programs dialog showing choices available for a product

Here, we have selected SQL Server Native Client, and three choices are appearing, Uninstall, Change and Repair. You can uninstall this product in two ways. You can select Change, then in dialog that appears, select Remove. Or you can just select Uninstall.

If you select Change, then Remove, you will still get the UI sequence during the uninstall. Meaning, you will still see dialogs and message boxes.

If you select Uninstall, the Windows Installer will only perform the Execute sequence during the uninstall. Therefore, no UI elements will be shown.

Here’s a screenshot showing the Add or Remove Programs section in the General Information view of an InstallShield project:

The Add/Remove Programs section in the General Information view

To ensure that UI elements are available during an uninstall, you have to disable the Remove button in the InstallShield project. That way to uninstall, the user will be forced to choose Modify/Change in the dialog. When he does that, he will be then be presented with a dialog that has three choices Modify, Repair, and Remove. And when he selects Remove, he will see the UI elements you have set up.

That always works.

This generally happens when you are working in the InstallScript view of a project. I think it usually happens in Basic MSI projects.

Anyway, you are working away and all of a sudden, you can no longer paste info into the script. No matter what you do, you can’t paste.

The solution is easy. Just save your project, close the project, exit out of InstallShield, then run it again, reopen your project, and go back to the InstallScript view. You will then be able to copy and paste again.

A simple solution to a problem you may encounter.

Here are the exact words on this subject from the Windows 7 Client Software Logo document:

All application data exclusive to a specific user and not to be shared with other users of the computer must be stored in Users\UserName\AppData.

What this means is that, when you are setting the value for INSTALLDIR in Basic MSI or InstallScript MSI projects, you should use the AppDataFolder.

Finally, if your application and data will only be installed for the current user of a computer, you are creating a Per-User installation.