Friday, 6. March 2009 at 9:49 pm
Last night I was looking around to see how ASP.NET MVC was doing and noticed Phil Haack posted that ASP.NET MVC RC2 was available. I was disappointed that the RC2 was basically all setup work. My immediate thought was, "Why didn’t they get that stuff right in the first public release?" My second thought was, "Does that mean that previous releases have a poor setup that might be messing up machines?" My third thought was, "Hmm, I installed ASP.NET MVC Preview 4, Preview 5, and RC1… I might have one of those messed up machines."
I went to sleep and woke up this morning to find Phil Haack had a new post titled Troubleshooting Windows MSI Installers. My immediate thought was, "A product waited until the last possible moment to focus on their setup and now there are problems. Color me surprised." My second thought was, "MSIZap? WTF!?!"
Note: I’m picking on Phil a little here because he leads with some poor recommendations on his very popular blog with a generic title of "Troubleshooting Windows MSI Installers". It could really lead people down the wrong rabbit hole and misses an opportunity to actually improve the ecosystem.
MSIZap? WTF!?!
My visceral reaction to Phil’s post kicked in when I saw him recommending MSIZap at the top of his blog post. Phil has most of the right disclaimers in place by basically suggesting that MSIZap is a last resort tool. Unfortunately, he puts it up front as the first and most effective option to get unblocked.
There are three major issues with MSIZap and the poorly named Windows Installer Cleanup Utility:
- MSIZap nukes the registration of the product from the machine but does not actually remove anything the product installed. That means all the stuff you installed is still there and there is now no way to uninstall it (except by hunting it down manually). That left over debris leads us to issue number two.
- Your machine is now in an unknown state. The information about what is installed has been surgically eviscerated and when you install the next version (assuming you do that) it will be dealing with debris that it was not designed to encounter (due to issue number one above). Way back when in Office, I’d sometimes get a tester saying that the new build failed to install and they were blocked. After looking at a very bizarre error case for entirely too long, I’d ask exactly what steps they took to get into this state. They’d say, "Oh, I just MSIZapped the previous install." I would nod and say, "Cool, you invalidated your machine. Format and start over." I was nonchalant about it because MSIZap removed our ability to debug the root issue, which brings me to the third point.
- You have lost the ability to figure out what went actually wrong. Debugging Windows Installer failures is a matter of analyzing a verbose log file captured from the failed setup operation. As noted above, MSIZap removes the ability to do that. Now, Phil actually provides the information how to do that (msiexec /l*v or the Logging policy). Unfortunately, rather than asking people to send failed logs to his team for diagnosis, Phil proposes people MSIZap when uninstall fails thus moving into a non-debuggable unknown state.
Orca? FTW!?!
Now I love Orca as much as the next setup developer but I would never recommend that users (even if those users are developers) open my MSI package with the editor and start cutting out pieces. That’s like suggesting that a user go in with an assembler and edit a compiled binary to work around a crashing bug.
Phil even suggests that "Editing the MSI is not really encouraged since it may cause other problems such as failing to uninstall properly." That or failing to install the product correctly or pretty much anything else. In my mind this is just another way to get into a completely unsupported state. I don’t know why Orca is listed as a solution to the problem.
Windows Installer? NO FAIL!
Typically, when this sort of things happens I see everyone pointing at the Windows Installer as the root of the problems. To his credit, Phil does not blame the Windows Installer and there is only one comment on his blog at the time of my writing that does. I make this point because based on the information presented it appear that the root of ASP.NET MVC’s failure issues are all in systems developed by Visual Studio: NGEN and devenv /setup.
That means Phil should be able to walk across the hall or across the street and pass along a whole lot of "FAIL" to one or more teams. A follow up blog post today suggests that Phil has already started doing that which is fantastic. My hope is that he will go further and help Visual Studio fix two pieces of the deployment world that I’ve also found (in my experience with the WiX toolset) to be fragile. The devenv /setup is of a particularly poor design.
What would I have done differently?
Phil’s heart is clearly in the right place. He wants all developers to be able to experience the glory that is ASP.NET MVC and doesn’t want its installation to deter from that experience. I can get behind that desire so here’s what I would recommend doing differently:
- Ensure setup is ready from the beginning and that everyone uses it. As Phil is discovering, there are lots of different machine configurations to take into account. Get your setup testing started as soon as you have a build to hand out. I know a lot of developers like to have a "batch file" setup that has all kinds of special ways to get things installed on their machine. They do this to be "faster" or just to "avoid setup". That approach ends up being detrimental to the product because you are now maintaining two ways to install and the one that gets used the most (by the developers and testers for day to day stuff) isn’t the one that gets shipped. Finally, when setup is done at the last minute (like RC2) those design decisions that were made early may come back to bite you.
- When you have a problem, make a plea to have anyone with a setup failure to send in log files. ASP.NET MVC is built for technically savvy people so it should be easy to post instructions on how to capture those logs. ASP.NET MVC also seems to have a pretty strong community built around it, so I believe they would have flooded the team with data.
- With the data build a solution. I expect that a new MSI could be built to address the problems. Then you send the fix and instructions out to all of those with the problem. It would probably be something like a recache/reinstall (msiexec /fv, a supported switch) over top the problematic install then uninstall. That way the machine stays in a known state and the setup incrementally improves.
- With the data go improve other parts of the platform. ASP.NET MVC isn’t alone in their installation woes with NGEN and devenv /setup. By turning their installation problem into an opportunity to learn they can help improve other parts of the system that are shared with many products. Then everybody wins.
Original post by Rob Mensching
