Smart Software Installer - resume at last failure

Question

Hello folks,

Has anyone out there ever written your own software installer in .Net that has a "pickup at last failure" ability baked in?

e.g. Let's say the install copies a bunch of files, registers some DLLs, sets up/manipulates a database (MS SQL), and sets up a data driven web site (IIS) that uses said database.

If the database manipulation part fails, exit the install program, fix the issue, then rerun - only this time the installer skips over the file copying and DLL registration, and picks up with the database work.

I could certainly write my own XML log file that the installer can find and drive the process, but rather than reinvent the wheel, I'm wondering if there is an established pattern & practice, or industry standard way to do this?

I searched the web for "software install resume" and, of course, I'm getting all kinds of résumé writing tips. Are there more topically-accurate keywords that anyone can suggest?

Thank you, TimD

Answer 1

I don't know your case or reasoning for wanting this feature, but it doesn't sound like the best idea. From an administrative standpoint, I really like it when installers function atomically - they either succeed or fail and undo any changes that they've made to the system.

That way when I re-run the installer, I don't have to worry about previous components being "left behind" and causing issues. In an ideal world, I also don't want to be prompted for things like overwriting existing files, because I don't know what version of some third-party DLL should be used for the application.

So for something like setting up or manipulating a SQL Server database, I'd want the database statements to execute within a transaction that could then be rolled back. It'd probably be smart to take a database backup, depending on the extent of the changes, but you might not have to bake that into the application. I like how Red Gate tools have a step for taking a backup built into their data synchronization process, so it keeps me safe and still keeps the process simple and streamlined.

Here's my reasoning. If I run an install and call it "MySite," and it makes a database and IIS virtual directory called MySite, and that install fails, under your reasoning, the DB and IIS directory are going to be left hanging around. Now if I'm an admin, I don't want to assume that your installer will cleanly deal with the existing pieces, so I make the next install MySite2, and go in and try to manually clear out the pieces of MySite.