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

 

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

 

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.

 

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."

 

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);