The purpose of this example is to illustrate how you should use the various options for components to give your users the power to install only what they really want or need, but without asking too many questions.
| Component name | Default | Selectable | Requires |
|---|---|---|---|
| Core files | Yes | No | - |
| Handy utility | Yes | Yes | Core files |
| Example support dll | No | No | Core files |
| Funny examples | Yes | Yes | Core files, Example support dll |
| Boring examples | No | Yes | Core files, Example support dll |
| Utility examples | Yes | Yes | Core files, Handy utility, Example support dll |
Core files: This component is marked to be installed by default and not user selectable. Thus, it will be installed no matter what (unless the user aborts the installation before any files are copied). It is also marked as required by all other components. This has no effect since it is always installed, but you should mark it anyway so you remember its purpose whenever you need to update the installation package.
Handy utility: Marked as installed by default, since it is very likely that the user will want to install this component. However, it is user selectable so advanced users of your software who can live without this “handy utility”, can conserve disk space. The extended description of this component should convince new users that they really want this.
Example support dll: Not marked as installed by default, since it serves no purpose if the user is not installing any example components. It is also not user selectable, since it is very clear when this component needs to be installed and when it should not and thus we will not bother the user with offering an option that is not really an option. Since it is marked as required with all three example components, it will be installed when one or more of these is selected by the user, overriding the default. If none of the example components is marked, only the default option will be left and the support dll will not be wasting any disk space. Note that you could also add the dll file to all three of the example components instead of making it a separate component. The user would not notice the difference (it will be placed in the setup package only once, so even the file size will not increase), but it does make it easier for the developer (you) to maintain the installation program.
Funny examples: Installed by default, but can be deselected by advanced users or people without any sense of humor.
Boring examples: Not installed by default, but the user can select them if he really wants them.
Utility examples: Installed by default since the utility is also installed by default. Since it is marked as user selectable, the user can install the utility without the examples. However, since this component requires the utility component, the utility examples cannot be installed without the utility itself.
You see that even in this small artificial example, all four possible combinations of “install by default” and “user selectable” make the setup package nice and convenient. The user is not confronted with core files and support DLLs (unless she takes the Advanced Installation route), which would be difficult to explain if she is new to or does not really care about computers. But still she can select and deselect whatever she desires that is not essential to the application.