Thoughts about setup and deployment issues, WiX, XNA, the .NET Framework and Visual Studio
All postings are provided AS IS
with no warranties, and confer no rights. Additionally, views expressed
herein are my own and not those of my employer, Microsoft.
IMPORTANT UPDATE - I have posted an updated set of steps for working around package load failures. Please read that blog post instead of this post because it contains additional information not listed here. I do not want to take this post down because I want to keep the comments so others can read them, but this post is essentially obsolete due to the new blog entry I have posted.
Since the final release of Visual Studio 2005 and the .NET Framework 2.0, I have heard from several customers who have been using beta versions of VS, SQL and .NET 2.0, and have followed the uninstall steps to the best of their ability (including trying the auto-uninstall tool linked at the top of the uninstall instructions page) but are still encountering Package Load Failure error messages in the VS IDE after installing the final release.
If you currently have the final release of any version of VS 2005 installed (including the Express Editions), and you are encountering package load failures, here is what I recommend that you do to resolve these issues:
1. Try to run the VS 2005 troubleshooting tool
Before trying the next set of steps, please download and run the VS 2005 troubleshooting tool. This tool is built on the same code base as the auto-uninstall tool, but it has knowledge of some specific problems that existed in previous beta versions of VS 2005 and knows how to go in and surgically clean them up.
2. Try to run the following command line to clear out the native image cache
Click on the Start menu, choose Run and type cmd, then type rd /s /q %windir%\assembly\NativeImages_v2.0.50727_32\Microsoft.VisualStu# and press enter to remove native images from the cache.
3. Manually search for orphaned files in the GAC
I have found that there are some cases where some additional files are getting orphaned on the machine that my test scenarios haven't caught yet (because we shipped a lot of different beta versions and I don't have the time to test out every uninstall permutation, etc). If I haven't seen the issue in my testing, it hasn't been added to the troubleshooting tool and therefore that tool won't always be helpful.
In general, the orphaned files that cause package load failures are located in the GAC (which is located at %windir%\assembly on your machine). So, if you have already run the troubleshooting tool and are still running into package load failures, here are some additional steps that have proven useful in identifying additional orphaned files:
I have found it useful to import the contents of c:\file_list.txt into Excel and then sort alphabetically by column G (which is the file version column). That makes it easier to zero in on files that have suspicious version information.
Please note that you will need to change the paths in the steps above if you have your OS installed on a drive other than C. Also, make sure that you include the trailing \ after the "assembly" folder name or else the FSnap tool will not work correctly.
4. Help me make the troubleshooting tool better
If you use FSnap and manually delete files and that resolves the package load failures you are seeing, I would appreciate it if you could let me know which files you removed that fixed the issue (either via the contact form or a comment on this post). If I see common problems that the tool is not yet able to fix, I can add them to the tool and post an updated version to help everyone else out who might hit the same issue.
Hopefully this will help resolve any lingering package load failure issues that you might be seeing. If these steps still do not work please contact me and let me know.
<update date="11/18/2005"> Added an additional step to clear out the native image cache based on findings I posted here </update>
<update date="12/16/2005"> Added an updated link to a newer set of steps at the top of this blog post </update>
Ever since the final version of Visual Studio 2005 was released, I have been hearing from customers who
I get the package load failures in vs 2008. I would like to know if the version numbers mentioned in the first few paragraphs up the top in this blog for removing files ("...is not equal to 50727.42" ) is still applicable or it is a different #s that we need to use for vs2008 as opposed to that for vs 2005
Hi Srinimv - The version for VS 2008 is 9.0.21022.08. However, as noted at the top of this blog post, this technique for manual removal is typically only useful if a previous beta of the VS product in question was installed on the system in the past. If you didn't have a previous beta of VS 2008, this technique will likely not help.
What I suggest trying to do to narrow down package load failures further is to run devenv.exe with logging enabled like the following:
"%ProgramFiles%\Microsoft Visual Studio 9.0\Common7\IDE\devenv.exe" /log %temp%\devenv_log.txt.
Then go look in %temp%\devenv_log.txt in Notepad and search for errors or warnings. The errors/warnings will list HResult values that you can hopefully use to narrow down the root cause of the package load failures further.
Note, the path to devenv.exe listed above is for a default install of VS 2008. The path will be different if you are trying to launch VS 2005 (it will be in the Microsoft Visual Studio 8 folder instead of the 9.0 folder). The path will also be different if you have VS installed to a non-default path.