Prevent an Entry in Add/Remove Programs

There are times when doing an installation that you don’t want an entry placed in Add/Remove Programs. Yes, I know it’s against the Windows Logo requirements, but sometimes clients/companies want it that way, for whatever reason.

In any Windows Installer-based InstallShield project, Basic MSI or InstallScript MSI, follow these steps:

  1. Go to the Direct Editor view.
  2. Go to the InstallExecuteSequence table.
  3. Delete the RegisterProduct action row from the table.
  4. Delete the RegisterUser action row from the table.
  5. Delete the PublishProduct action row from the table.
  6. Delete the PublishFeatures action row from the table.
  7. Go to the AdvtExecuteSequence table.
  8. Delete the PublishProduct action row from the table.
  9. Delete the PublishFeatures action row from the table.

After you do this, when you run your installation, it will do all the work you want it to, but the application will not be registered with Windows and will not show up in Add/Remove Programs or Programs and Features.

Now, this means that there will be no maintenance functionality in your installation. So, you have essentially created a wrapper installation where you have all the functionality of InstallShield available to you, but without the entry showing up in Programs and Features.

 

Small Bug with Signing Patches in InstallShield 2014

I had an issue in a client project where I was signing a patch and when I applied the patch, the first dialog that came up looked like it hadn’t been signed. But, when I went to Programs and Features, clicked View Installed Updates and uninstalled the patch, the signature showed up in the first dialog.

I called InstallShield tech support about this and they confirmed it was a bug in InstallShield 2014. However, there is a workaround.

Go to the Direct Editor, select the ISPatchConfigurationProperty table, SignaturePassword property, and change the encrypted password to a plain-text version password.

Fixing the patch signing bug in InstallShield 2014

Fixing the patch signing bug in InstallShield 2014

You may consider this workaround to not be ideal, because if you store IS projects in XML format, anyone could look in there and maybe see your certificate password in plain text (haven’t checked it though). But unless you distribute your project files, you should be safe until the IS 2014 service pack comes out.

 

Silent Installs of Third Party Installations Don’t Always Work

I recently did a couple of projects for clients that involved running several third party installations silently from the script. These were both InstallScript MSI projects. I have done this many times over the years, but this time I encountered something different.

I found that silent installs of third party installations don’t always work. Even when their documentation says they are supposed to work. This is not InstallShield’s fault, but rather the third party’s.

Just so you know, I always launch third party installations in InstallScript similar to this.

Using LaunchApplication with Third Part Installations

Using LaunchApplication with Third Party Installations



In the above screenshot, you see how I typically set up a call to LaunchApplication. This is a simplified example, so all I have for the command line is the /s option. Generally, there would be more options than this.

I like using SdShowMsg to display a message to the user during the silent install. If you don’t do that, you just have a progress dialog sitting there with nothing going on, which may cause the user to think the installation has hung.

Notice at the end if there is an error, I get the actual error code returned. If you just test for values that are ISERR_SUCCESS (meaning success) or < ISERR_SUCCESS (meaning failure), you are only seeing whether the call to LaunchApplication was successful or not. Not the actual error returned by the third-party installation or whatever it is that your running.

If the silent install doesn’t work, then you can play with the options you are using, which may help. But in the end, you are sometimes at the mercy of the third-party installation developer. And whether or not they did a good job implementing the silent install.

I suggest removing InstallShield from the equation and run the silent installation from an administrator command prompt to see if it works there. In the projects I was working on, it didn’t change anything.

If you can find no way around your problem, then you have to decide what band-aid is the best alternative for the end-user. And maybe the best solution is not to band aid at all.

Talk it over with your company or client and determine the best solution.

 

Get Order Right When Using Custom Dialogs and Dialog Skins

There is a certain order of doing things when you want to use dialog skins with custom dialogs in InstallScript-based projects.

Here is the proper order:

  1. Open your InstallScript-based project in InstallShield
  2. Go to the Dialogs View and select a Dialog Skin.
  3. Create your custom skinned dialog.

That’s the trick. Select the skin first, then create the custom dialog. If you do it the other way around, the skin won’t be displayed on the custom dialog.