This post is out of date; please see: The correct way to uninstall Visual Studio packages (extensions)

I ran into a small problem uninstalling dotCover from Visual Studio 2012 this morning and had to complete the removal manually.  Due to the recent popularity of NuGet and the word “package” in the .NET space, finding the right search terms was difficult.  In the end, however, it wasn’t hard at all.

First a short disclaimer:

dotCover is a code coverage tool by JetBrains that integrates with ReSharper.  I have no real thoughts on the tool itself one way or the other as my trial ran out before I found a need or use for it, hence the uninstall.

And now back to our story.

I started through one of the usual routes, clicking Uninstall in the ‘Programs and Features’ dialog.

Most of the uninstall experience was painless and came off without a hitch.  I did notice a pair of dialogs stating that something was not allowed, which I proceeded to ‘OK’ my way through without apparent effect.

All appeared well, until I started up Visual Studio 2012 and was greeted by this message:

The 'JetBrains.dotCover.Product.VisualStudio.v11.0.Package, Version=2.1.471.44, Culture=neutral, PublicKeyToken=1010a0d8d6380325' package did not load correctly.

The problem may have been caused by a configuration change or by the installation of another extension.  You can get more information by examining the file 'C:\Users\davida\AppData\Roaming\Microsoft\VisualStudio\11.0\ActivityLog.xml'.

Continue to show this error message?

image Looks like something didn’t quite work right after all.

Following the dialog’s instructions I opened up the ActivityLog.xml file.  Here’s the relevant section: Notice the GUID embedded there:

  • {7FFD1A80-7A5A-49B2-A39B-491C750984FF}

I wondered if Visual Studio relies on the registry to decide which packages to load, and if perhaps the part that failed in my automated uninstall process was merely the registry cleanup related to removing the bits.

Sure enough, thanks to this post on Stack Overflow I cracked open RegEdit and found a Packages node at:

  • HKEY_CURRENT_USER\Software\Microsof\VisualStudio\11.0_Config\Packages

and it contained a node with a matching GUID and values that included a path to the missing dll that Studio complained it could not find.

Deleting that node resolved the problem.  No more warning dialogs when starting up Studio and no noticeable side effects.

One final tip on searching for a GUID using RegEdit.

Remember the GUID we were looking for?

  • {7FFD1A80-7A5A-49B2-A39B-491C750984FF}

Notice the curly braces?  Extension package GUIDs are embedded in a pair of curly braces.


If you search for the GUID without the braces and have that ‘Match whole string only’ option checked, you won’t find it.


Including the braces in the search term (or unchecking the option) will find it just fine.