Tagged InstallShield

[simage=105,320,y,left]Recently, while trying to set up some Logitech QuickCam Messengers in one of our public computer labs, I ran into an Internal Error 2738 displayed by InstallShield during the installation process. A quick Google search turned up some information that indicated the error is caused by VBScript not being enabled on the computer. This may be because it was turned of for security (in Windows XP), or because it comes disabled for security by default in Windows Vista. To enable it, simply launch a command prompt (in Vista, you will need an administrative cmd prompt, which you can get by typing ‘cmd’ into the Start menu box and then right-clicking on the cmd icon and choosing “Run as administrator”). Type the following into the prompt:

regsvr32 /u vbscript.dll

That should allow you to re-run the installer successfully. You might want to disable VBScript again afterwards (no idea if it is necessary to run the app) for security. To do that, type the following:

Since I started creating MSI installers for Windows XP’s Windows Installer, there are a few bad habits that I’ve apparently let slip into my work, and Vista is quickly showing me when and how. The first one I found is that Vista’s Installer doesn’t let you mess around at will, as long as you’re installing from an account with administrative privileges, as XP basically does. Instead, you have to carefully consider what you’ll be doing with your install logic, then run any Custom Actions in a such a way as to pass Windows Installer’s new, far more robust, checks.

Stefan Krueger of installsite.org has written up a nice list of 7 reasons (PDF) why your installer might fail in Vista, even though it cooks right along in XP. I immediately noticed I was guilty of #2, and thanks to Stefan and the recent acquisition of InstallShield 2008, I was able to quickly modify my previously unusable installer (based on Alan‘s successful Ghost AI version) for McAfee ePO and have it run on Vista for the first time.

It’s interesting also to note that #6 on the list explains that the built-in Administrator account in Vista is actually different from the other ‘administrator’ accounts created in the OS. That’s why right-clicking an executable and choosing ‘Run as Administrator’ can often have different results in Vista than simply running it through, say, your own administrative account.

Of course, it’s not always a good idea to go ahead and run your CA in the system context. I found out why pretty quickly when all of our systems started reporting in with the username ‘SYSTEM’ in ePO, denying us a sometimes useful piece of information that we used to have in XP, namely the last logged-in user on a particular system. But, while we’re still in the wild west era of Windows Vista, anything that makes an installer work is welcome news.

In an effort to provide additional security in Windows Vista, Microsoft has added the User Account Control (UAC) dialog prompts. Since these run on a special ‘secure’ desktop that is technically just an image of your actual desktop, so traditional means of manipulating the dialogs don’t work. However, Microsoft hasn’t left MSI developers out in the cold. The Windows Vista blog has a great article about automatically handling the different types of UAC dialogs you’ll encounter in Vista. As a developer, you’ve probably turned the UAC off on your machine, but you obviously have to assume your end users have it turned on, so this is a hurdle that must be overcome when packaging apps for deployment.

Most of the work you’ll need to do involves the application’s manifest, which the blog article clearly sketches out and provides an example of. There is the typical amount of grousing in the comments, no doubt since Vista is uncharted territory and Microsoft isn’t the greatest at providing an immediate response on new problems in their technology. However, it’s great to see that these additional security features have been added without entirely handicapping developers–although there will no doubt be a slight learning / frustration curve to overcome first.

Now, to install InstallShield 11.5 on a new Vista box. Exciting commentary and reviews to follow!

I’ve been working a lot recently with Macrovision’s AdminStudio package, which includes their popular InstallShield .msi creation software. While it’s safe to say that InstallShield provides a serious level of drag-and-drop ease with their product, it’s also equally safe to say the $1500 price tag is probably out of the reach of most home users who, say, want to package up their GPL app into a nice, clean installer format. That’s where Orca comes in.

A free app available from Microsoft as part of their massive (>1.5Gb) SDK, but better acquired on its own as a tiny download from Aaron Stebner’s blog. The direct link for download is here.

Now, Orca obviously doesn’t include all of the GUI features that you’ll find in InstallShield-after all, it’s a free product from Microsoft-but it’s certainly good for what it does allow you to do: make quick and easy edits to existing .msi’s and create simple installers for free. I recently used it to add in several products to the Upgrade table for an existing installer, a task which is particularly simple with Orca’s direct editing interface. Also, in spite of being less drag-and-drop than its expensive Macrovision cousin, Orca does feature really helpful pop-up dialog boxes that provide the user with paradigms and expected values to enter into the MSI tables, a feature that will be of great help to those just getting started with creating .msi’s. All in all, it’s a really nice tool for Microsoft to hand out for free, and something fun to have on your computer to spy on the inner workings of other people’s installers.

InstallShield 11.5 provides an easy way to search the registry for a desired value

Oftentimes when creating a new installer, it is necessary to provide for the contingency of previously installed software that will need to be removed. This can be a previous version of the same software (although those modules should maintain the same unique IDs, making this extra procedure unnecessary) or it can be a piece of software that will conflict with the software you’re trying to install (i.e. an old anti-virus program). Either way, in order to effectively remove the software, you’re going to need to:

1) Search for the program’s existence, and
2) Run its UninstallString from the registry.

Thankfully, InstallShield provides a couple of easy ways to accomplish this. The first (ideal) way to run the other software’s uninstaller is to do a simple system search for the registry key UninstallString for the program you wish to remove. The advantage to this method is that the search is very specific–it only looks within a particular key–so you can easily do 100 of these searches in the course of an install. In order to create the appropriate Custom Action within your MSI in this manner, do the following:

1) In the ‘System Search’ screen, add a new search by right-clicking and choosing ‘Add…’ (or hit Ins).
2) Choose ‘File Path, as specified by a registry entry’ at the next screen.
3) For the Registry Root choose ‘HKEY_LOCAL_MACHINE’
4) For the Registry Path type ‘SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\**ProgramName**’ (in other words, to uninstall Macromedia Flash, type ‘SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Macromedia Shockwave Player’
5) Under the optional Registry Value field, type ‘UninstallString’
6) Pick a memorable name for your new file-path variable like FLASH8PATH, then choose the top option to only store it in the tables, not use it as an install condition (you will attach the custom action later).

Your System Search is now complete, and will look for the UninstallString for Flash Player, then store that value to the variable FLASH8PATH. If you wish, you can immediately use this variable to create Install Conditions for different Custom Actions, either as an exists/does not exist check that launches an .exe or something, or by using the actual path contained in the variable. To launch the uninstaller, create the following Custom Action:

When creating installers, it’s often necessary to stop running processes before beginning the actual install. For example, while creating an install of McAfee’s VirusScan Enterprise 8.0i, I discovered I needed to kill about 10 different processes associated with the free trial of McAfee Security Center and Personal Firewall that’s been showing up on all the new Dell laptops being shipped to my work. The trial is seriously insidious, since declining the free 90-day offer and closing all the appropriate windows, andexiting from anything McAfee-like in the system tray does nothing to stop those processes. They just keep on going, unless you end them from the Task Manager.
Now, for the purposes of rolling out VirusScan Enterprise to over 1,000 computers in the course of a few days, it would be rather impractical to ask users with varying degrees of computer savvy to terminate processes in a designated order prior to installing VSE.
Now, InstallShield has the built-in ability to call VBscripts within a Windows Installer (MSI), and you can launch a batch file from the installer easily by calling cmd.exe, as described on this MacroVision support page.
However, I found the VBscript solution was limited in its scope, as the ability to terminate a process does not extend to services. In order to kill a service (or SYSTEM process), you need to write a separate VBscript to kill services, since the command to terminate a process in userland will not translate over.
As to the batch file approach, you need to install the file first, then run it, since you can’t stream it into the binary data, so it plays havoc with your installer if you need to terminate processes before you copy files.
After trying a few batch files launched from the command line, and meeting with varying degrees of failure (probably due to my ignorance of proper sequencing), it occurred to me that there was a really simple way around this mess: taskkill.
Taskkill, otherwise known as the command I was launching from the batch file I was copying over to the destination machine in a nested MSI, can be launched in InstallShield 11.5 quite easily. Basically, you point the Working Directory over to the [SystemFolder] in a Custom Action, where taskkill.exe lives on every Windows NT based system. Then, enter the following command line:

“[SystemFolder]taskkill.exe” /f /im (processname)

In other words, to kill notepad.exe, type:

“[SystemFolder]taskkill.exe” /f /im Notepad.exe

Remember to set the Custom Action to ‘Synchronous (Ignores exit code)’ to avoid erroring out because of a lack of response from taskkill.exe after it terminates the designated process. I suggest placing these actions immediately after the CostFinalize action in the Execute sequence of the standard install.
Using this method, I was able to easily kill all 10 processes running with McAfee’s free trial software, and toast the software itself by running its uninstaller. An elegant and simple solution, arrived at through truly miserable and misguided trial and error.