For every upgrade, update or patch you create, you have a second chance to create a great first impression with your end users. In the “Installation Best Practices: Tips for Building Upgrades, Updates and Patches” webinar, attendees were eager to learn best practices to follow when creating and deploying an update-friendly Windows Installer (MSI) installation. Here are the top questions and answers from the webinar.
1. Q: When do I use a major upgrade versus a patch?
A: First, ask yourself how it will impact your business development needs. If you don’t have time to do thorough testing and QA, then major upgrades are a lot safer and less likely to fail. But sometimes your business needs require only a patch.
2. Q: If we made an error while creating the MSI, is it better to create an upgrade or recreate the MSI?
A: In general, a major upgrade is the best of both worlds. When you create a major upgrade, you can essentially recreate your MSI from scratch. As long as you are respectful of the component rules, it can be done.
3. Q: Do you need to uninstall the existing version explicitly before installing a new major version? Can we include the uninstall action in the same MSI?
A: When you author a major upgrade through InstallShield, it will detect if the older version is on the target machine and perform the uninstall automatically as a part of the upgrade process.
4. Q: Can you please explain how / if InstallShield helps in creating a major upgrade using an InstallScript+MSI project. I ran into issues where feature and the INSTALLDIR were not migrated.
A: An InstallScript MSI project still uses MSI technology to perform the installation operation while allowing for a more customized UI that is handled with InstallScript. Creating a major upgrade for an InstallScript MSI should be similar to creating a major upgrade for a Basic MSI. However, if desired, migrating feature states and preserving INSTALLDIR must be handled through custom code.
5. Q: For follow-up patches, does the “previous” package mean the most recent patch?
A: When you’re dealing with minor upgrades that target RTM, each patch will target the original version and assume the intervening versions do not exist. Each patch has the information to apply not only to the base but to each intervening version. And that’s when may encounter cumulative effects as far as the size of your patch. But regardless of which approach, you need to ensure that each patch you release is cumulative in terms of the changes it makes to the machine, otherwise you’re likely to orphan information on the machine.
6. Q: Can I use Dynamic Linking when building patches?
A: Yes, but you have to be careful. If your development team removes files, or moves them around, you may encounter some issues. But if you development team does not delete or move files, Dynamic Linking can save you a lot of time. Be sure to track your changes and you should have no problems.
7. Q: What does it mean for a file to have accurate version information, especially when you’re dealing with files from Java (JAR or WAR files)?
A: From a Windows installer perspective, that’s a problem case. These files do not have what Windows Installer sees as a version block, so it is going to consider them as non-versioned files. Without versions, things like time stamps can even influence whether files get replaced during upgrades. That is not an ideal case to be in. But when you’re dealing with Java, it’s one of the hurdles you have to overcome.
8. Q: Can I use merge modules to author my updates?
A: Merge modules are enigmatic: they can either cause problems or can be perfectly well behaved. From the perspective of authoring your project, merge modules are a black box. If you’re using the same version of the merge modules over and over, you’re always going to get the same registry, etc., and nothing will change and everything will work out. But if it’s a merge module from another vendor, and they’ve released an update to it, and you want to include that, the changes they’ve made can impact how you can chose to package that update. And if you treat it as just a black box, then you won’t know. The only safe approach is to create a major upgrade. If you’re authoring it yourself, you can decide if you want to follow all the same rules that you would inside the main project inside your merge module and then be able to use it as a minor upgrade, major upgrade or whichever you choose.
9. Q: What types of major updates are supported?
A: One point of view is that major upgrades are like an uninstall, followed by an install. But that’s not always true. You typically see it as just an install of a new version, you don’t have to ask your customer to uninstall the old version. If you’re using a major upgrade to get around some big changes you had to make in your product, then you probably want to uninstall the old product early. That gives you the most flexibility. If you choose to schedule the removal later, then you have to pay a little more attention to component rules, and it’s more likely that you will run into some of the scenarios where a file looks like it should be fine but gets deleted. There are a lot of potential reasons that could happen (for example, there are some oddities with the global assembly cache that are even worse). But, in general, if you follow the component rules on major upgrades, you should not see that sort of thing. Just make sure you increase your file versions.
10. Q: Where can I find training on InstallShield?
InstallShield® is the world’s leading Windows installation development solution. InstallShield is designed to enable development teams to be more agile, collaborative and flexible when building reliable InstallScript and Windows Installer MSI installations for desktop, server, Web, virtual and traditional applications. The software installer of choice for today’s sophisticated application producers, InstallShield is the only software installer that can directly convert MSIs to Microsoft App-V virtual packages. Get your free trial of InstallShield today or contact us for more information.