Update on root cause of Package Load Failures in VS 2005 beta 2


I got a chance to investigate a couple of machines from Microsoft employees who ran into issues after trying to uninstall VS 2005 and .NET Framework beta 1 and installing VS 2005 and .NET Framework beta 2.  The machines I looked at had problems because Package Load Failure dialogs appeared when launching the IDE or creating projects in VS 2005 beta 2.  I was able to fix the machines by doing the following;



  1. Locate all of the files in %windir%\assembly that had file versions starting with 2.0 or 8.0 where the 3rd part of the file version (not the assembly version) does not equal 50215 (the VS 2005 and .NET Framework 2.0 beta 2 build number)
  2. Open a cmd prompt and manually delete the files and folders that were in that list

The most common problem I saw was that there were 2 copies of the file Microsoft.VisualStudio.Shell.Interop.8.0.dll in the GAC, one from beta 1 and one from beta 2.  For some reason, the beta 1 version takes precedence when devenv.exe launches and the VS IDE package fails to load.


I am working on compiling a full list of assemblies that exhibit this behavior and once I get that, I will update my cleanup tool to automatically remove these files.  However, I probably will not be done until sometime tomorrow so I wanted to post a manual workaround in the meantime for anyone who reads this blog post.  Hopefully I'll be able to save some drive reformatting and make beta 2 installation and usage a little less painful.


Technical details if you are interested


In both cases that I investigated today, the .NET Framework beta 1 was uninstalled before VS 2005 beta 1, and that caused VS 2005 beta 1 uninstall to fail to remove some assemblies from the GAC because fusion.dll is used to install/uninstall assemblies and since fusion.dll was installed as a part of .NET Framework 2.0 beta 1, it was removed by the uninstall and was therefore not present to perform the GAC uninstall during VS 2005 beta 1 uninstall.


This uninstall issue should cause all VS assemblies to be orphaned in the GAC.  However, installing VS 2005 beta 2 should update the versions of the files in the GAC because they have higher file versions in beta 2 than in beta 1 (since the bug I described here has been fixed).  But there is one critical issue that causes a few of the assemblies to not be updated.  In the case of the file Microsoft.VisualStudio.Shell.Interop.8.0.dll that I listed above, it contained metadata that identifed it as an MSIL assembly in beta 1, but the MSIL tag was removed for beta 2 for some reason.  So Fusion treats it as a completely different assembly and uses a different physical location on disk to store it in the GAC, and as a result the machine ends up with 2 copies of that file.  I haven't gotten a complete list of orphaned files yet, but my theory is that all of the other orphaned files are caused by similar metadata changes.


Really in-depth technical details if you are really interested


This problem theoretically exists for VS 2002/.NET 1.0 and VS 2003/.NET 1.1, but there is a design change we took in the .NET Framework 2.0 that makes this problem worse.  In 1.0/1.1, you will see the .NET Framework create a folder under %windir%\system32 named UrtTemp that contains copies of a few files that Windows Installer uses to install assemblies.  These files are needed because the .NET Framework contains the code needed to install assemblies using the MsiAssembly and MsiAssemblyName tables, but it also needs to install assemblies itself (the classic chicken-and-egg problem).


In 2.0, we wrote a custom action to call fusion APIs directly to install assemblies because of a limitation in Windows Installer that would not let us use the DuplicateFile table if we needed to install files to the file system and the GAC.  This liimitation had caused us to carry 2 copies of each assembly in dotnetfx.exe, which caused the download size to be unnecessarily high.  In order to reduce size of the .NET Framework we had to use this custom action, which is why you see Assembly and AssemblyName tables in netfx.msi and do not see anything in the MsiAssembly and MsiAssemblyName tables.


Because we implemented this custom action, we were also able to eliminate the part of setup that copied files to UrtTemp.  In the past, uninstalling .NET Framework would leave behind the files in UrtTemp so that assembly uninstall could be accomplished by using those copies of the fusion files.  However, in 2.0 we don't use UrtTemp so after 2.0 is uninstalled, there are no files left behind to use for future GAC uninstalls.  Visual Studio setup does not fail and rollback if GAC uninstall fails because we decided that if a user chooses to uninstall and files are left behind, we should not rollback and add all the files back to the machine.  For a released product that is probably OK, but for beta versions, that can cause orphaned files that interfere with future releases of the same product as seen above.


The other complicating factor here is that the .NET Framework is a prerequiste for any application that is written in managed code (such as parts of Visual Studio), but we do not have any way of reference-counting the .NET Framework to prevent the user from uninstalling the .NET Framework out from under any applications that need it.  Because of this, even though we know that uninstalling .NET Framework 2.0 beta 1 will cause orphaned files when you try to uninstall VS 2005 beta 2 later on, we cannot prevent the user from performing the uninstall.  We have iterated over several proposed designs to create a reference-counting scheme but found too many confusing scenarios where we would pop up dialog boxes strongly suggesting that the user not uninstall, or scenarios where we block uninstall when we should not, or scenarios where 3rd party applications failed to increment reference counts because it requires extra work that was too obscure or difficult.  So for 2.0, we will have to live with this type of behavior.


I suppose the ultimate answer will be close to what I always wanted to see - the .NET Framework is a system component that is not uninstallable.  You see that on Windows Server 2003 where .NET Framework 1.1 is part of the OS and is always present, and you will likely also see this on Longhorn for .NET 2.0.


 

Comments (15)

  1. There’s a few technical problems you mention above.

    The fact that the file versions of the assemblies are higher has nothing to do with the GAC, actually. Fusion uses the assembly version.

    For this reason and because Microsoft doesn’t change assembly versions after RTM, the MsiAssembly and MsiAssemblyName tables are also not used becuase – up until recently – Fusion wouldn’t overwrite the assemblies and assumed (arguably correctly) that the assembly version would change and assemblies would be installed side-by-side. For this reason, .NET actually uses Assembly and AssemblyName tables (dropped the "Msi" so that they weren’t processed by MSI itself) and uses their own custom actions. This also supports servicing since, again, the assembly versions aren’t changed – only the file versions are.

  2. I’ve posted an updated version of the VS 2005 and .NET Framework 2.0 cleanup tool that will fix Package…

  3. Heath, thank you for posting additional details about these scenarios.

    In some cases Fusion will use file version to determine whether or not to replace files in the GAC, but only when the rest of the assembly’s identity (assembly version, language, processor architecture, etc) are the same. There was a bug in the Fusion file replacement logic but that has been fixed in .NET Framework 1.1 SP1 (I described it at http://blogs.msdn.com/astebner/archive/2005/02/12/371646.aspx)

    In .NET Framework 2.0, the setup package itself does use the tables named Assembly and AssemblyName and a custom action to install assemblies to the GAC. We didn’t decide to do this due to any problems in Fusion though or due to any policy decisions regarding updating assembly versions for servicing. That decision was made purely to reduce the size of the .NET Framework redistributable package by eliminating duplicate copies of assemblies being carried with the setup. We only use this custom GAC installation method in redistributable packages we produce that install duplicate files to the GAC and the local file system and that we want to keep the size as small as possible for (.NET Framework, J# redistributable, .NET Framework language packs, etc). We use standard MSI tables for all Visual Studio SKUs.

  4. If you have had Visual Studio 2005 beta 1 installed and then removed it and installed VS 2005 beta 2,…

  5. ScottyW says:

    I had the same errors after the following:

    0. build fresh win server 2003

    1. install sql 2005 april ctp (to e:)

    2. uninstall visual studio 2005 (was on c:) – part of the sql install.

    3. install visual studio 2005 (on e:)

    4. open devenv, help, about – errors for all sql packages.

    5. uninstall sql server 2005 tools ctp, development tools.

    5a. devenv, help, about opens with no errors and no sql packages

    6. reinstall sql server 2005 tools ctp, development tools.

    6a. devenv, help, about opens with no errors and with sql packages.

  6. superlatch says:

    Still seeing this problem in SQL Server 2005 Books Online (after clicking search):

    —————————

    Microsoft SQL Server 2005 – Microsoft Document Explorer

    —————————

    Package ‘Visual Studio Common IDE Package’ failed to load.

    Tried all removal methods; ran clean-up tools etc. removed SQL Server 2005 CTP; removed .NET Framework 2.0 etc. No luck. Any help appreciated.

  7. Hi Benjamin – I had another customer run into a similar issue earlier this week and I couldn’t resolve it by simply running the cleanup tools for some reason. Here are the steps that finally worked for him, can you try this out and see if it works for you as well?

    1. Run the VS beta 2 cleanup tool from http://astebner.sts.winisp.net/Tools/ttool.zip

    2. After the cleanup finishes, manually cleanup %windir%assembly by doing the following:

    Open a cmd prompt

    Run cd /d %windir%assembly

    Run rd /s gac_32, rd /s gac_msil, and rd /s for any of the native images folders

    3. Follow the steps at http://blogs.msdn.com/astebner/archive/2005/05/10/416223.aspx to cleanup the VC runtime files

    4. Search for any files on your system with version numbers beginning with 2.0.50727 or 8.0.50727 and if any exist delete those manually

    5. Try to reinstall VS beta 2 one more time

    Hope this helps….

  8. C.K. Chua says:

    Hi Aaron, my VB Express Beta 2 was downloaded last week and I had a smooth week testing and using it to create apps. Unfortunately, after an uninstallation effort, I am now having problems trying to install VB Express back. I tried the steps you mentioned in this posting (Oct 14th 2005), but when I click on the VBsetup, an error message will pop up during the installation, stating, "…indicating a problem with this package, error 2908". And even though I have remove all .Net framework (except my old .Net 1.1), the installation package only installs the VB Express Edition + the MDSN (optional) and SQL April CTP (optional). It does not install the .Net Framework 2.0 Beta 2 edition.

    Now, if I install .NET Framework 2.0 (ver 0727.26) before running vbsetup.exe, the installation can be completed successfully. However, upon creating new projects or opening existing projects, it will pop up "the Package Visual Studio Common IDE Package has failed to load…." message.

    Please help. And a side question, when Express Edition is out of Beta, will it continue to be a free programming tool? Thanks, Aaron.

    You can also email me at ckchua(at)jl-software(dot)com. Thanks alot.

  9. I did run into package load failures when I installed the RTM of VS 2005 because of older Beta 2 bits lying around. I had to run the clean-up tool multiple times and each time it still reports that more information is being cleaned. Is there some iteration of the tool that will report that no more beta bits are around? The reason I’m asking is, although I’m almost 95% fine with my VS 2005 IDE, I still get some issues when I’m using the BI Studio of SQL Server 2005. Everything loads fine, but some toolbar controls do nothing and I’m not sure if I need to run the cleanup tool more times.

  10. 第一篇:

    VS2005包加载失败 卸载2005,如果卸载的不干净的话,再次安装容易导致

  11. McGurk says:

    No beta versions ever installed on this PC.  I have been using VS2005 since 12/05 without the Package Load Failure issue.  Friday the error occurred as I was working with the SQL Server 2005 db in VS2005 IDE.  I do have SQL Server Express also on my machine but have had it on my PC and use it but it has never caused a problem.  

    The specific error I get is:

    Package Load Failure  

    Package ‘Microsoft.SqlServer.Tools.PublishWizard.VSCommands.MenuCommandsPackage, MenuAndCommands, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bg3856ad364e35’ has failed to load properly ( GUID = {A38CF415-6AD2-45F6-8132-9CC33EBE0629}).  

    I have not uninstalled and reinstalled VS2005 because I would rather find the cause and address it.  Can you help with this?

  12. McGurk says:

    I have now uninstalled and reinstalled SQL Server 2005 and Visual Studio 2005 also.

  13. Hi McGurk – I’m sorry for the hassle this issue is causing for you.  I don’t have any specific experience troubleshooting load failures for this package.  In general, it often helps to launch the VS IDE with logging enabled to try to narrow down the root cause of a package load failure.  To do that, you can run something like the following:

    C:Program FilesMicrosoft Visual Studio 8Common7IDEdevenv.exe /log %temp%devenv_activity_log.txt

    Then you can go to %temp%devenv_activity_log.txt and search for errors and warnings.

    If you don’t see anything useful in that log, you can send it to me via email and I can try to see if I can figure anything out.  You can send the log to Aaron.Stebner (at) microsoft (dot) com.

    It might also help to post a question on one of the SQL Server forums at http://forums.microsoft.com/MSDN/default.aspx?ForumGroupID=19&SiteID=1 to see if anyone there can help suggest any possible workarounds.

Skip to main content