Is it the Tool or the Author? Part II

Philip Hofstetter responds to my post about Windows Installer in an attempt to clarify his post.  I say attempt, because to me it looks like he just repeats his same points without saying anything different.  Philip claims that the behaviors he calls out are all attempts to work around some flaw in Windows Installer.  He claims that these poor developer habits are an annoyance to the end user when installing a package:

• Bootstrappers for the MSI runtime
• Bootstrappers for application prerequisites
• Embedded 3rd-party scripting engines
• Wrapping a traditional EXE style install in an MSI
• Installing things EXE-style and just using the MSI to register the product on the machine

I’ve already covered the idea that these items represent “flaws” in my previous post on this topic, so I won’t repeat my position here.  He also refers to previous blog posts (here and here) he has made on Windows Installer where he complains about:

• Files in his %TEMP% folder
• Confusing repair dialogs

What I would like to cover here is Philip’s position that these items constitute some sort of hassle for the end-user.  So let’s go through them one by one:

• EXE bootstrappers for the MSI runtime
• Bootstrappers for application prerequisites

I’m at a loss why bootstrapping the MSI runtime or application prerequisites onto a machine would be considered a hassle to the end user.  Its been my experience that end users are appreciative of application installations that ensure that the machine is appropriately bootstrapped for the application so that they don’t have to chase down the prerequisites and install them manually.  Furthermore, by bootstrapping prerequisites (and the MSI runtime is just another prerequisite) for the end-user you ensure that the appropriate prerequisite for your application is on the machine.  For many prerequisites, there are different versions and its easy for end-users to install the wrong version (or even the wrong prerequisite) and be frustrated with your application installation because it refuses to proceed when the wrong version or prerequisite is installed on the machine.  The user thinks they are satisfying the prerequisite, but the code needs a specific version that isn’t there.

Of course, with insufficient attention to detail and inadequate testing, people can produce prerequisite bootstrappers that are fragile and prone to error.  This doesn’t help the end-user, but this is sort of stating the obvious — poor quality software, including setup software, is not helping the end-user.

• Embedded 3rd-party scripting engines

I don’t see how this is a hassle for the end-user either, unless of course its a quality issue.  Is it a best practice for setup developers?  I don’t think so, because it creates vendor lock-in.  But is it a hassle for end-users?  I don’t think so, unless you’ve got defects in your script such that one of your install, modify, repair, rollback, or uninstall scenarios fails.  Again, it comes back to the quality of the code created by the author and not the tool they used to create the code.

• Wrapping a traditional EXE install in an MSI
• Installing things EXE-style and just using the MSI to register the product on the machine

The main reason I’ve seen people asking for this in the newsgroup is that they want to use group policy to distribute an application throughout their organization.  Group policy can only distribute applications this way if the application is packaged as an MSI.  So if you only have a traditional SETUP.EXE style installation and you want to push it through group policy, your immediate lowest-cost implementation thought is to wrap the EXE in an MSI.  Its not the best solution, but it is one that is low-cost to implement and probably has the lowest risk of introducing defects into your application installation.  Is it a best practice?  Again, no, but I don’t think this harms or hassles the end-user provided that no defects are introduced along the way.  Depending on how you do the wrapping, you may lose repair or modify functionality for your installation.  However, I’ll be honest and say that install and uninstall seem to be the two scenarios that users care about most.  If they have to uninstall and then reinstall in order to modify the application’s configuration that might be an acceptable workaround, as long as you realize that it is a workaround and not a true modify scenario.

Now let’s take a look at the two complaints that Philip had posted in previous blog entries:

• Files in his %TEMP% folder

I must admit that when I read this, I got the impression that Philip just didn’t understand user profiles in Windows.  Lots of programs create temporary files in the %TEMP% folder.  In particular, Philip didn’t like seeing MSP (Windows Installer patch packages) and MSIxxx.LOG (Windows Installer log) files in his temporary files folder.  My immediate reaction was: “Dude, you know you can safely delete anything in your temporary files folder, right?”  Apparently doing this makes Philip nervous or he just doesn’t like having to clean up his temporary files folder.  At the moment, I have 653 objects in my temporary folder because this is my development system and Visual Studio .NET creates lots of temporary files in that location as I work on my code.

So why are MSP and MSIxxx.LOG files cluttering up Philip’s temporary files folder?  First, le’ts look at the MSP files.  Well, most applications use a self-extracting archive to apply patches so that they can invoke Windows Installer with the proper command line arguments to properly apply the patch.  They unpack the patch package into the temporary files folder and then invoke Windows Installer to apply the patch.  The MSP file is left behind in the temporary files folder.

As for the log files, if they have file names of the form MSIxxx.LOG, these are log files generated by the Windows Installer runtime based on machine policy settings.  The “xxx” is some pseudo-random digit string that makes the log file have a unique name.  If you have a lot of these files in your temporary files folder, then chances are you had the machine logging policy turned on at some point.  This causes Windows Installer to create a log file every time it runs, whether its performing an install, uninstall, repair, modify, or patch operation.  This is a very useful debugging tool, but this machine policy is not turned on by default and its unusual for programs to change the policy programmatically, although it can be done.  You can examine your Windows Installer log policy setting by doing Start / Run… / “gpedit.msc” to launch the group policy editor.  In the tree view on the left, drill down to Local Computer Policy / Computer Configuration / Administrative Templates / Windows Components / Windows Installer.  On the right-hand pane you will see a list of configuration values.  The Logging entry shows the machine logging setting.  To turn off automatic logging for this machine, double click Logging and change the value to Disabled or Not Configured (the default).

Are these temporary files a hassle for the end user?  No more so than any other application that creates files in the temporary files folder.  Every once in a while you have to go in there and clean it out.  Due to its nature, its safe to delete any file in the temporary files folder that is not in use.  It would be nicer for the end-user if the Windows Explorer provided a convenient mechanism of saying “hey, clean up all my temporary files please!”.  As it stands, I tell people to open a folder window and type %TEMP% into the address bar to navigate quickly to their temporary files folder so they can delete all the files. Finally, we come to Philip’s last complaint:

• Confusing repair dialogs that seem to come up for no reason and might demand the source media for an application that’s already been installed.

Now this is one complaint that I can agree with.  This behavior is most definately frustrating for end-users.  Windows Installer has detected some sort of damage to an application and tries to do the right thing by initiating a repair operation for the application.  In an ideal world, this would repair the problem and then the user would be able to get on with their work.  Unfortunately, most authors of installation packages don’t consider the repair, modify or upgrade scenarios when they test their installation package.  I’ve seen many questions in the newsgroup from frustrated users and authors with respect to this resiliency aspect of Windows Installer.  Part of the problem is that Windows Installer doesn’t present enough context about what its doing and why its doing it.  To the end user it looks like some randomly initiated install operation.  The end user is more likely than not to just cancel this operation, but that just defers the operation to happen again.  The worst part is that the repair operation may not fix the problem in which case the user is just treated to more and more of these automatic repair operations being initiated but not succeeding, making for a frustrated end user.

Philip wondered why sometimes when this auto-repair process was initiated why he was being asked for the source media for an application.  Well suppose Windows Installer initiated the repair because a file from the application was missing?  It needs the source media in order to repair that file and correct the problem.  That’s probably the most common reason why source media might be requested.  Sometimes the source media isn’t strictly necessary but due to a defect in the way the installation was authored, the source media is requested.  However, in a fashion similar to what happens when you cancel the automatic repair operation, if you don’t supply the source media you may just face the whole repair process all over again the next time you interact with this application or one of its resources.

Philip also wondered why these repair processes would be initiated when manipulating a resource that didn’t seem to have anything to do with the application in question, such as double-clicking on a file in Windows Explorer.  While I can’t say specifically what was causing this on Philip’s system without analyzing his system and its configuration, I can tell you that the seemingly simple act of double-clicking on an icon on the desktop or in a folder involves quite a bit of mechanics behind the scene.  First, the file’s type is identified.  Next, the type is used to look up what the default operation is for files of that type.  That involves looking in the registry for registered shell actions and registered file types.  The registry is one area that is “hooked” by Windows Installer in order to support resiliency (automatic repairs) and advertisement (installing an application on first use) scenarios.  When these hooks are activated, Windows Installer will perform a quick localized integrity check and may initiate a repair operation if it sees some sort of problem.

After reading Philip’s blog post about these annoying auto-repair dialogs, I got an idea for a tool that would diagnose the problem and attempt to inform the end user more specifics about the problem.  For instance, it might tell you that a certain registry value is missing, or a certain file is missing and so-on.  If I create such a tool, I’ll write a blog post about it here and provide a download link for obtaining the tool.  The details of the repair failure analysis are somewhat technical and only of concern to setup developers, not something that would be useful to an end user.  However, a diagnostic tool that automated the analysis and provided the end-user with relevant information would be helpful.

For all the items except the automatic repair issue, I am not seeing how these things are a problem for the end-user, assuming that the underlying installation package has gone through sufficient testing to ensure quality.  For the issue of the automatic repair dialog, I’ll be the first to admit that the process ends up being confusing for the end-user although the intention was to ensure application integrity by automatically repairing problems.  This dialog could be more informative to the end-user about why a repair was initiated.  Additionally, the behavior could be extended so that the user could say “ya know what, I don’t care if you think this application is damaged.  Just stop doing whatever it is you’re doing in an attempt to repair the application and don’t attempt this again.”  Of course, its not like Windows Installer just makes up problems that it encounters that send it into an automatic repair.  So if you cancel the repair and elect to continue with the operation regardless of whatever problems Windows Installer may have noticed, the requested operation may not work anyway.  But at least it would be your choice and you’d feel less at the mercy of Windows Installer and its automatic repair mechanism.