Configure when first run

Benefits

• Reduces support cost of misconfiguration of organization-specific settings by end-users.
• Better user experience!
• Supports roaming users
• Supports hoteling users

Description

Often, many setup authors assume that the best time to configure an application is at install time – that way everything is ready for the user once the product is installed. But configurations should be based on users, not the machine (unless you’re application is a service). Instead of allowing the user to configure the application at install time, let them do it the first time they run your program.

Of course, you’ll still need to register your application’s file types, ProgIDs, and ClassIDs as normal, but you should leave configuring program options and defaults until each user runs your application for the first time. While it is tempting to configure your application at install time, this is not a good approach for a several reasons:

• If you’ve followed the data separation guidelines earlier in this document, you’ll know that configuration should be done on a per user basis. Configuring your application at install time could violate some of these best practices.

• Your application should be able to run without being able to read any defaults from the registry. If you’ve hard coded defaults into your program, you shouldn’t need to duplicate this data in the registry.

• The environment you’re installing into could change between the time your program is installed and the time that a user first uses your application.

While delaying initialization until the user’s first run is a great approach to take for user applications, obviously this doesn’t apply to Services. It’s okay to initialize a service at install time, because services are typically machine rather than user specific. The usual caveats apply though, don’t forget that the environment can change between install and first run for services as well.

See Also

Data Separation Guidelines