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

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).


Comments (3)
  1. Ok, when do I get to say "I told you so"?

    I’ve been saying since Beta 1 of 2005 and SQL Server 2005 that your install/uninstall routines were the next DLL Hell and we’re degrading back to the days of Windows 3.1. When are you guys going to start listening to me and do something about this before it’s too late?

    Windows Installer is BROKEN. Completely and utterly. Only by fixing it can you fix what is causing this nightmare of uninstall. This isn’t going to get any better for RTM and you’re going to have manual uninstall tools and KB article decribing how to do it.

    This is why Linux SUCKS. This is one of the things that differentiates Windows from Linux. If you start making it a pain in the ass for people to uninstall software (no matter how technical the people doing the uninstalling) there is no reason to not use Linux.

    Get with the program MS. Fix this. I’ve told you how to do it. I outlined a complete plan and how to impliment it to your VP of the SQL Server group, I told them everything that’s wrong, and how to fix it.

    As it stands right now we can’t upgrade our application to SQL Server 2005 because it requires install feature selection dependant installation of MSDE (i.e. it’s only installed in one mode). We use the merge modules right now. We cannot use a bootstrapper because that would leave software on the machine that isn’t being used, and that’s the hight of bad software behaviour.

    Thus we’re left with staying with SQL Server 2000 or switching to My SQL which is free for our customers and thus saves them thousands of $$$ over SQL Server. We don’t want to, but you’ve forced us to because of Windows Installer and the problems that have been created because of the bugs in it and the complete lack of functionality to deal with merge modules correctly. (i.e. you still can’t create an MDAC merge module that works for Windows Installer after years of trying so you’ve made it an OS component…. then the SQL server group comes out with SQL Server Client which is just another MDAC by another name… brilliant)

    Fix this before release! Please!

  2. Hi James – can you provide me with more detail about your plan to fix these issues that you reported to the VP of the SQL group? Also can you provide more detail about what you mean about Windows Installer being completely broken? The MSDN issue I describe above isn’t caused by any flaw in Windows Installer, but I also recognize that Windows Installer is not perfect. I hope that I can understand your concerns better so that I can try to help come up with short-term workarounds and push feature suggestions and bug reports to the appropriate development teams. Please contact me at aaronste (at) microsoft (dot) com if you see this.

  3. Vivek Singh says:


    Any suggestions on how to reinstall Visual J# cleanly. My install (July CTP) broke after I had to kill VS 2005 a few times. After that no matter how many times I uninstall (from "Add/Remove Programs, msiexec, using your and Hong’s suggestions) and repair, it stays broken. I just downloaded the August CTP from MSDN (of VS 2005 Pro) and it came up with the same dialog (post-installation) which informs you me Visual J# is not installed correctly and I need to install followed by "devenv /resetpkgs".

Comments are closed.

Skip to main content