Software installation is often an afterthought in a development project, and teams often look toward the easiest or least expensive solution they can find. You can get a Windows installer that is easy to use and abstracts many of the features of MSI, or even cobble together your own installation scripts. But in doing so, you end up giving up many of the advantages of Microsoft’s MSI in forging a complete and accurate installation. True .msi files ensure quality and customer acceptance of installers and are the core of the installation process.
Here are five reasons why your team should be using a native MSI installer for Windows-based applications.
Reason 1: Application software is complex. Today’s applications can’t be installed simply by copying files onto a hard disk. A single application might consist of thousands of files. Application suites could have several different interrelated applications that have to be installed in the proper order, or that depend on the same set of DLLs. Abstracting away from MSI may sound attractive, for reasons of simplicity or expediency, but eventually application installation could become unmanageable.
Reason 2: Enterprises have corporate standards and need to push applications through client management tools. Large organizations don’t install applications one desktop at a time, but rather push out applications and updates via a tool such as Microsoft System Center. Without MSI, these organizations can have no confidence that application deployment completed successfully.
Reason 3: Creating an installer package for a new application is non-trivial. Release engineers have to be cognizant of files, file locations, registry keys, dependencies, user privileges, and other aspects of the hundreds or even thousands of components involved in an installation. A large amount of detail may have to be put into XML files or other formats that subsequently become difficult to maintain and change. Working directly with MSI installation processes enables release engineers to assemble robust install packages that rarely if ever have to be rewritten during the development lifecycle.
Reason 4: An MSI installer understands the target system better. Some of the decisions about an installation are made during the installation itself. A native MSI installer can query the system about storage required, memory, file locations, operating system version, and other essentials needed to ensure a successful installation. By being able to collect and incorporate specifics from the target system, a native MSI installer can warn users of incompatible installations, low disk conditions, and other characteristics that may affect the installation.
Reason 5: It makes uninstallation easier. Development teams that don’t plan for installation as a part of application design also typically neglect the need for a clean uninstallation. But users need to uninstall, as applications are updated or systems passed on to other users. Teams also have to plan for repairs, patches, updates to new versions, and other activities that don’t require a full and complete installation. In most cases, that means working directly with MSI.
Whether or not these top five reasons apply to your situation, it makes sense to follow Microsoft’s lead on application installation. Installation isn’t a sexy or particularly innovative engineering activity. It just has to be done, and it has to be done correctly. Microsoft develops and promotes MSI technology for good technical reasons. Application development teams seeking the right way of doing installation, without risk or concern about issues later in the development cycle, need to work with MSI at the beginning of the project and stick with it.
If you’re looking for an installation solution for your team, or even for a specific project, MSI is the place to start. After you look at the reasons for working with native MSI, alternative solutions aren’t likely to meet your long-term needs.
Learn why iPass uses InstallShield for creating native MSI installers for their Windows applications!