Now that Visual Studio 2005 and .NET Framework 2.0 beta 2 is about to be available, I wanted to communicate a couple of issues we have seen related to uninstalling previous beta and Community Tech Preview (CTP) versions that can cause problems when you try to install beta 2.
Uninstall should be done in the reverse order of installation
I’m sure you’ve noticed the large number of entries that are added to your Add or Remove Programs control panel after installing Visual Studio. There are a lot of sub-products being installed silently as a part of Visual Studio setup and there are some specific ordering issues that are enforced during install because Visual Studio manages the chaining of the installation. But the ordering is not enforced during uninstall. The biggest problem we have seen is that uninstalling the .NET Framework before trying to uninstall Visual Studio, the J# redistributable, MSDN, or SQL Express will cause those other products to leave behind files in the GAC. This is because the .NET Framework is the ship vehicle for Fusion, which is the technology that manages GAC install/uninstall. So, in general the safest way to uninstall is to treat the list of products as a computer science stack and uninstall them in the reverse order they were installed. Hong Gao, a program manager on the setup team, has posted sets of instructions on her blog for the Visual Studio 2005 Express SKUs and for other Visual Studio 2005 SKUs that I strongly recommend you follow.
Uninstall for previous versions of the .NET Framework 2.0 may not be completely clean
Most often, the way you will notice this issue is if you see a failure while installing a future version of the .NET Framework 2.0 after uninstalling a previous version. You can find a detailed explanation for how to workaround this issue in my previous blog post.
After installing Visual Studio, the IDE may fail to launch or you may see multiple Package Load Failure error dialogs
This is caused by some known issues in previous beta and CTP versions related to installing native Win32 assemblies to the %windir%\WinSxS cache. To workaround these issues please try the following steps:
- From a cmd prompt, run eventvwr.exe
- Go to the System event log and look for error logs with the event source SideBySide
- Find the name of any assemblies mentioned in these entries in the System event log
- Go to %windir%\WinSxS and rename the folders with names that are the same or similar to the entries in the System event log (for example *.VC80.*)
- Launch Visual Studio 2005 setup again, and choose to repair the product
As always, please let me know if any of these workarounds do not work for you. Also, I strongly encourage you to use the MSDN Product Feedback site to report any bugs that you find with uninstalling previous versions or installing new versions. I’ll update my blog with other common issues and suggested workarounds as they arise.