How much logic is too much logic

[Ray_Portrait]

Hi,

This is a thread that I am hoping will generate some attention. Basically what I want is feedback about what should be expected from an installer.

I have worked on several different projects over the years and have seen a variety of different techniques used when it comes to the installers.

For installers that stick the sheer basics such as deploying files and doing minimal configuration using the fewest install paths are always easier to maintain and upgrade from. The downside is that you have to rely on external processes / applications to configure what the installer doesn't.

For the more complicated installs that have multiple install paths and do everything under the sun are nightmarish to maintain but give the user at install time (which can be overwhelming) to completely setup their environment.

I believe that the immediate response would be to strike a good balance between install runtime config and external config. The sticking point for me is to determine when this balance has been met and how to convince project managers that have little to no InstallShield knowledge. How many dialogs is too many? How many install paths with different configuration settings is too many (this in particular gets messy very quickly).

I am a big fan of having post install applications to do configuration that may happen more than a once off in an installer instead of running in maintenance mode to reconfigure these user files.

In a nutshell, I believe that people generally mistake install technology to be a programming tool rather than a way to deploy your software.

Any feedback about this will be greatly appreciated!

[cbragg]

When i do my installations I take the view of do just as much as is needed to get the user up and running out of the box without doing anything extra, everything else is set to a best fit default.

If you HAVE to configure something before you can even use the application then you have more work to do. If you're getting the user to trawl through dialogs then you've gone too far. Everything else can then be sensibly set through settings of the application

If the advanced user wants to do more configuring they can but you have to allow a simple user not to have to do anything more if they don't want to.

One thing i find a lot of installations fall foul of is over configuring pre-requisite stuff like trying to create windows accounts and large backups. I find it's ok if it's a simple runtime to install but I don't think you should be taking away some of the more complex administrative tasks that an administrator would prefer to do themselves mainly for security reasons. Here a good guide should surfice with maybe a warning dialog refering to the guide (because lets face it most of us don't read them unless we have to)

[Johannes_T]

Hi Ray,
only a few words about this subject. IMHO its hard to say if install technology is mistaken for configuration tasks. IS provides a lot to enable a complex configuartion process and I don't really see a reason to use a second tool for this.
However, there are projects I agree that people mistake this. For example, I'm currently helping on a project which uses InstallSheild in a very old version for such a complex configuration management that the scripts have a size of about 50.000 LOC (yes, in IS!). And thats really an amount which would lead me to another more powerful language.

So, I'd say: IS for small projects / external tools for large projects.

Greetings

[KathyMorey]

I agree with one of your points - in my opinion, you should run an installer to install or to uninstall. Period. If you have to run the installer on a product to change configuration options, you've put stuff in the installer that doesn't belong there.

For the rest, my company used to try to do everything possible in the installer to configure the product, back when we used primarily InstallScript. Now that we've switched almost exclusively to MSIs, we've changed our philosophy a bit. We set up Web sites and virtual directories and install services, but we don't setup databases or try to add users. We don't automatically set any settings that we believe a system administrator would want to know about.

We have a couple utility programs that we instruct our customers to run after installation to do some of the other configuration stuff our product requires and that then allow them to also changed configuration info later.

I personally would rather have too little in the way of extras inside the installer than too much.

[dan_galender]

I agree with moving configuration out of the installer--especially if that configuration can also be used post-installation. The installer could easily install a configuration program, launch it at the end of the install and then have it available to be run later on, stand alone.