Common Questions About Standard Patches

Posted on 16 March 2010 by Rod_Maupin

One of my InstallShield Training course customers recently asked me several questions regarding a Standard Patch he was building. Since these were good questions, I thought I would pass the answers along to you.

Here are the questions:

Q: Can the patch remove a folder (and associated files) that was installed during the initial installation of a product?

A: Well, no. If you try to do this in a patch, you will get a build error as InstallShield will think you are trying to do a major upgrade. This is assuming you have set the Windows Installer codes correctly for the patch. In the end, deleting a folder of files in an upgrade is a large enough change to not be considered a patch anymore. Now, a major upgrade acts like a first time installation if no previous version of the product is installed. You can specify whether you want the previous installation to be uninstalled before the upgrade installation (the newer version) takes place. If you do, the folder will be wiped out during the uninstall of the previous product, and that would take care of your folder.

Another scenario is where you would want to add a new folder of files during the upgrade. That would also require the upgrade to be a Major Upgrade.

Q: Can user decide whether to delete the old folder or not?

A: In the last question, we determined that deleting a folder meant we would have to do a major upgrade. You might be able to write a custom action to display a dialog to the user before the upgrade takes place, they decide whether or not they want the folder, then you handle it in another custom action during the Execute sequence. This is an iffy situation. I have never done it, and I am actually not sure if it can be done. It’s probably getting into messy, dangerous territory. But again, I don’t know for sure.

Q: Can I rename Update.exe to something else that is more descriptive?

A: Yes, if you have InstallShield create the patch in an Update.exe file, you can rename it to anything you like after the patch has been built. Just find Update.exe and rename it. If you elect to not create an Update.exe file, you would have to go to the patch file and rename it. Remember a patch file has the .msp extension.

Hopefully, that clears up some confusion about Standard Patching.

 

Custom Action Conditions in InstallShield

Share and Enjoy:
  • Digg
  • del.icio.us
  • Facebook
  • NewsVine
  • Reddit
  • StumbleUpon
  • Google Bookmarks
  • Yahoo! Buzz
  • Twitter
  • Technorati
  • Live
  • LinkedIn
  • MySpace

Leave a Comment

Security Code:

Signing a Release Fails in InstallShield 2011

When I first downloaded and used InstallShield 2011, I noticed that when you try to sign a release in the Releases view, it will fail. This applies to Basic MSI, InstallScript MSI, and InstallScript projects. This has since been resolved, so I thought I would point out a Knowledge Base article to you. Here is the link: Q210261: HOTFIX: Building a Signed Release Fails with Error -1027 The hotfix has an attached zip file with a new version of IsWsBuild.ocx. Unzip the file and place it in the following folder: C:\Program Files\InstallShield\2011\System

 

[gwa-autoresponder listid="#1"]

InstallShield 2011 Was Released Today

InstallShield 2011 was released today by Flexera Software. It promises more features and abilities for your installation development pleasure. Get it while it's hot: InstallShield 2011 Now Available

 

[gwa-autoresponder listid="#1"]

The Perils of Nested Installs and the Windows Installer

A frequent question is how do you do a nested install in a Windows Installer project in InstallShield? I'll just come right out and say they are not recommended. Which is a nice way of saying, "Don't do it!" Here are some problems associated with nested installations:
  • Nested installations exist under the context of the parent application, and because of this do not appear in Add/Remove Programs. The only way to uninstall them is to uninstall the parent application.
  • There is no such thing as a nested progress bar in a nested installation. So, you don't have feedback with the child installs.
  • Upgrade installations are probably not going to work with a nested install. This includes patching.
  • Nested installs can not share Components.
  • An Administrative installation will probably not allow nesting of other installs.
  • You will probably have unpredictable results if a child install crashes. Will the parent install continue? Maybe, maybe not.
Now, InstallShield has always allowed nested installs in Windows Installer projects, but in the context of using it's own bootstrapper, Setup.exe. The bootstrapper installs the Prerequisites before the main installation takes place. Another type of nested installation allowed is called a Chained Installation. This option became available with Windows Installer 4.5 support in InstallShield 2009. In a Chained Installation, you add the child MSI files to the parent install in the Releases view. When you run the parent installer, it is installed first, followed by one or more child installs. This works well, and the parent and each child installation show up in Add/Remove Programs. So, you can uninstall all of them by uninstalling the parent. Or you can uninstall them individually by uninstalling one or more of the child installs first. That's what I know about nested installations. If anyone has anything to add, please leave a comment.

 

[gwa-autoresponder listid="#1"]

Problem Installing Windows Installer 3.1, and a Solution

I took a side trip through Windows Installer 3.1 Hell today. I didn't intend to, but when you're a Windows developer and user, these things tend to happen, and at the most inconvenient times. I had a Win XP SP2 test machine where Windows needed to be repaired, and being very adventurous, I booted from the XP SP2 CD and chose to do a Repair installation. I hadn't done one in a long time and had forgotten that it's scary as hell to do. The repair went off without a hitch. Except for the fact that I needed to go to Windows Update and get all the updates. Okay, I thought. There goes a couple hours of my time. But, I didn't get off that easy. I couldn't update anything because I needed Windows Installer 3.1. I thought that wouldn't be much of a problem, and I was wrong there too. No matter how many times I tried, it would get 3/4 of the way through the WI 3.1 install, and then give an "Access Denied" message. When you get that, it rolls back the changes, and then you have to restart Windows. I went to the net for a couple hours and tried many unsuccessful solutions that I won't go into. Eventually, I ran into the solution. When you do a Repair installation of XP SP2, if leaves you with only the Everyone account configured. And that is the reason Windows Installer 3.1 won't install. Because you need to add your user account to do it. To do this, you run regedit, click HKEY_CLASSES_ROOT, then in the Edit menu select Permissions. You will see that the only listing is for Everyone. The article I read said to add Administrator and SYSTEM, and give them Full Control. Then add your user account and do the same. After I did all that, I was able to install Windows Installer 3.1 with no problems. Hopefully, this will save somebody some trouble in the future. P.S. Yes, I know this post was about the Windows Installer, and this is supposed to be an InstallShield blog. However it is related, since it deals with an installation problem. P.S.S. Here's the article I referred to. I only performed Step 2 for my particular problem: Message: "You do not have access to the registry key HKEY_CLASSES_ROOT or one of its subkeys. Please change the permissions then launch setup again."

 

[gwa-autoresponder listid="#1"]

Control Visibility of Dialog Controls at Run-Time in InstallScript

If you have the need to enable/disable dialog controls at run-time in an InstallScript project, there is an easy way to do it. You can use the _WinSubEnableControl() function in your script. The first parameter is the handle to the dialog. The second parameter is the control name. The third parameter handles the visiblity. Here's the call:           _WinSubEnableControl(hwndDlg,RES_PBUT_RESTORE,0);           0 makes the control invisible           1 makes the control visible Here's an example showing the use of the function:           // set dialog name           szDialogName = "CustomCustomerInformation"; ;          // get the handle to the dialog           hwndDlg = CmdGetHwndDlg(szDialogName);           // disable the Email Address edit box           _WinSubEnableControl (hwndDlg,CCI_EMAIL_ADDRESS, 0);           // enable the Email Address edit box           _WinSubEnableControl (hwndDlg,CCI_EMAIL_ADDRESS, 1);

 

[gwa-autoresponder listid="#1"]