I have been working with Hong and Andrey on an updated version of the VS 2005 beta cleanup tool. During the course of investigating potential problems caused by uninstalling in the "wrong" order (by which I mean uninstalling the .NET Framework 2.0 beta 2 before uninstalling other parts of VS 2005), I found an interesting issue. There are 2 assemblies installed by VS 2005 that shipped in beta 2 with no file version information. These files are the following:
When .NET Framework 2.0 beta 2 is uninstalled before VS 2005 beta 2, VS is unable to remove assemblies from the GAC because fusion binaries were removed during .NET 2.0 uninstall. This causes all VS assemblies to be orphaned in the GAC. Most of those assemblies will be updated in-place when installing a later build of VS 2005 because the assemblies in the later build have higher file versions. However, these 2 assemblies do not get replaced because they were unversioned in beta 2 and have been updated to have valid file versions in later builds. It appears that fusion will not replace an unversioned file with a versioned file in this type of scenario.
When the old beta 2 versions of these files are left in the GAC and you try to use specific features in the VS IDE, you can receive package load failures. For example, if you open a C# Windows Application and right-click on a .cs file and choose View Class Diagram, you will receive a package load failure error for the Visual Studio Class Designer Package.
To work around this issue, you have to replace these 2 unversioned assemblies in the GAC with the versioned assemblies that ship with later builds of VS 2005. The trick now becomes how to find these files on the VS 2005 source media. Here is how I found them when I was verifying the fix on a test machine in our lab. Please note that the VS 2005 troubleshooting tool will perform these steps automatically and I also posted a separate, simpler set of manual steps to fix this issue, but I am including them here for those who are interested in how I went about troubleshooting this issue.
- Open the VS 2005 MSI in Orca
- Go to the File table, press Ctrl + F and search for each of the files
- Take note of the Sequence value for each of them
- Go to the Media table and sort by LastSequence value in order to find the cab that each file is in on the VS 2005 source media
- Go to the VS 2005 source media and extract the files from the cabs listed in the Media table
- Rename each of the files after extracting them (becuase the files in the cabs will be named with the identifier from the File table and not the actual name so that Windows Installer knows how to find the files in the cab during installation)
- Open a cmd prompt and navigate to the proper locations in the GAC and copy the newly extracted files to the locations and overwrite the unversioned files that were left behind
- Relaunch VS and verify that the previously broken scenarios now work and do not show any package load failures
The GAC locations for the 2 files in question are the following:
- %windir%\assembly\GAC_MSIL\Microsoft.VisualStudio. EnterpriseTools.ClassDesigner\ 220.127.116.11__b03f5f7f11d50a3a\ Microsoft.VisualStudio.EnterpriseTools.ClassDesigner.dll"
- %windir%\assembly\GAC_MSIL\Microsoft.VisualStudio. EnterpriseTools.SdmDesigners\ 18.104.22.168__b03f5f7f11d50a3a\ Microsoft.VisualStudio.EnterpriseTools.SdmDesigners.dll"
If the above steps are too complicated, you can also use gacutil or a cmd prompt to remove the old versions of those 2 assemblies from the GAC and then run a repair of the newer version of VS 2005. This is an easier process but will take much longer due to the time it takes to repair all of VS 2005.
After re-reading all of the above, I realized what a pain this workaround is. Fortunately, we're nearly done automating it so that if you inadvertantly uninstall VS 2005 beta 2 without using the prescribed uninstall order, you'll be able to use the updated version of the cleanup tool to fix this. Stay tuned for a post very soon with details about where to download the updated cleanup tool.....
<update date="11/7/2005"> Added links to automated cleanup tool and simpler set of manual cleanup instructions for this issue in case people find this blog post but not the other posts I've done about this issue </update>