MSDN for VS 2005 beta 2 will fail during uninstall if .NET Framework 2.0 beta 2 was uninstalled first

  • Article

While working on some of the new steps needed in the cleanup tool that will help folks moving from VS 2005 beta 2 to post beta 2 CTP builds and eventually to the final released version (you can get a preview version of this tool here), I found a bug that I wanted to alert people of just in case. If you uninstall the .NET Framework 2.0 beta 2 before you try to uninstall MSDN for VS 2005 beta 2, MSDN uninstall will fail and report a fatal error. To workaround this I had to re-install .NET Framework 2.0 beta 2.

Of course, I know that the .NET Framework 2.0 beta needs to be installed last when removing previous beta bits to prepare to update to a newer beta, but not all customers will read the fine print on the web or in the readme. And this uninstall order is not enforced in the code at all. So I wanted to give a heads up just in case.

I ran the MSDN uninstall with verbose logging and this is the exact error that caused uninstall to fail:

MSI (s) (58:10) [20:12:54:810]: Executing op: CustomActionSchedule(Action=CA_RepairArchive.3643236F_FC70_11D3_A536_0090278A1BB8,ActionType=3073,Source=BinaryData,Target=RepairArchive,)
MSI (s) (58:8C) [20:12:54:830]: Invoking remote custom action. DLL: D:\WINDOWS\Installer\MSI737.tmp, Entrypoint: RepairArchive
Action ended 20:12:54: InstallFinalize. Return value 3.

Apparently this custom action needs something in the .NET Framework to run correctly in beta 2. Fortunately, this scenario was discovered and fixed and I validated that MSDN will uninstall correctly even if the .NET Framework 2.0 is not installed in more recent builds.

As a side note - this is a really frustrating user experience to have uninstall fail and rollback. In this case I was trying to remove the product, and removal fails so it rolls me back to the state where it is still installed. In addition, in order for MSI to support rollback it has to reserve extra disk space to cache the rollback data in case of a failure and uninstall takes longer because it has to cache rollback data before starting to uninstall.

We faced similar issues in Visual Studio setup, and after examining the data and getting bugs reported about setup reporting that the machine did not have enough disk space to uninstall, we made a decision early in the development cycle for VS .NET 2002 to disable rollback during uninstall. This ended up speeding up the uninstall time from about an hour to less than 5 minutes (in most cases), plus we no longer received bug reports about not having enough disk space to uninstall. We were initially worried that uninstall failures would leave the machine in a bad state and prevent future installs, but found that to be extremely rare in beta versions of VS .NET 2002 and ended up shipping that way (and we also shipped VS .NET 2003 that way and intend to ship VS 2005 that way as well).