Handle your dependencies

Benefits

• Reduces user frustration due to incomplete installs
• Increases reliability
• Makes the application functional in more situations

Description

Nobody wants to be too dependent on others, and in an ideal world your application should have as few dependencies as is reasonably possible. That’s not to say that you should ship every possible dependency in your shrink-wrapped product, just be intelligent about what you really depend on.

Sometimes handling dependencies is as easy as abstracting features from feature requirements. For example, an image manipulation program with scanner support should be able to install and run fine, even if there isn’t a scanner installed. Your application would simply disable those features that depend on the scanner.

Of course this approach doesn’t work for everything. Dependencies on specific libraries, like ODBC are a little harder to handle. A database client application isn’t very useful if it can’t connect to the server, but there could be many different reasons you can’t connect (LAN down, server down, ODBC problem, security, configured incorrectly). While each of these issues has different root causes, the bottom line is that the user can’t do their work. In all of these cases the application should start successfully, and “fail gracefully” by reporting the error and disabling the affected features. Just exiting might be an option, but if there’s anything the user can do to fix the problem inside the application, leave it running. They know how to exit!

Add-ons are more obviously dependent. If the application (or architecture) they extend isn’t present, they aren’t useful, even if successfully installed. In these circumstances you might want to warn the user the application isn’t present, but allow them to continue anyway. Even though the application isn’t there, someone else might be able to use you; it’s also possible that the user just decided to install you first!

Here are the three basic different kinds of dependencies in terms of how it affects install, and suggestions for handling them:

• Things you depend on that your company makes. An example would be a business rules object your application needs to use. If multiple applications your company creates uses these, or you offer them separately, they should be included as Windows Installer Merge Modules. Otherwise it’s okay to just include them as their own component in the product install.

• Things you depend on that you don’t control, but can ship with your product. These are often called redistributables. These should be included with your install in the form of Merge Modules. You should get these Merge Modules from the company you get the redistributable from. If you offer components for redistribution, you should include a Merge Module for others to use.

• Things you depend on, but can’t redistribute. First, avoid being dependent on these. If you must have them, then immediately check for them in your install. There’s no point continuing if you don’t have what you need to run. An example here might be a version of the operating system. If your application needs to run on at least Microsoft ^® Windows ^® 2000, but the user is trying to install it on Microsoft ^® Windows ^® 98 Second Edition, let them know, and quit.

See Also

Support Just-In-Time installation