||Carlos J. Quintero (Microsoft MVP)
||Microsoft Visual Studio 2005
||Microsoft Visual Studio 2008
||Microsoft Visual Studio 2010
||Microsoft Visual Studio 2012
This article explains how to debug Visual Studio assemblies (source code not
available) using the .NET Reflector commercial tool (http://www.reflector.net/) to diagnose
problems with Visual Studio extensions (add-ins, packages, etc.).
The requirements are the following:
- An edition of .NET Reflector that allows to set breakpoints in code (F9), even
if you don't have the source. At the time of this writing (version 7.6.1), only
the VSPro edition allows this (the VS and Standard edition don't).
- Visual Studio 2010 or 2012 as the debugger IDE, since the .NET Reflector
package only integrates with these versions (Visual Studio 2005 or 2008 don't).
In the example provided, the installation of an extension through the
Extension Manager of Visual Studio 2010 will be debugged using Visual Studio
2012. The steps are the following:
- In the debugger IDE (Visual Studio 2012), show the .NET Reflector
Object Browser toolwindow (".NET Reflector", "Show .NET Reflector Object
Browser" menu). For this example we will use Visual Studio 2012.
- Create a Class Library project.
- Save the solution (so that the .NET Reflector Object Browser shows the
references of the project, it doesn't show them with temporary solutions).
- In the Project properties window, "Debug" section, select the "Start external
program" radiobutton and select the Visual Studio 2010 IDE: C:\Program Files
(x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe.
- In the Solution Explorer, add a reference to the Visual Studio assembly that
you want to Debug. While the folder "C:\Program
Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE" contains Visual
Studio assemblies (and the "PrivateAssemblies" and "PublicAssemblies"
subfolders), Visual Studio actually uses the assemblies that are stored in the
Global Assembly Cache (GAC):
- For Visual Studio versions using the CLR 2.0 (Visual Studio 2005 and 2008), the
GAC is the folder C:\Windows\Assembly. Since this folder has a shell extension,
to reference assemblies in this folder see the article
HOWTO: Reference a Visual Studio assembly in
the GAC from an add-in.
- For Visual Studio versions using the CLR 4.0 (Visual Studio 2010) or CLR 4.5
(Visual Studio 2012), the GAC is the folder C:\Windows\Microsoft.NET\assembly,
which is browsable directly with the Windows Explorer. For this example, select
the assembly Microsoft.VisualStudio.ExtensionManager.Implementation.dll (in the
that implements the Extension Manager of Visual Studio 2010.
Note: you can know the actual location of an assembly loaded by Visual Studio
using the Process Explorer tool (http://technet.microsoft.com/es-es/sysinternals/bb896653.aspx), locating the devenv.exe process, and clicking the "View", "Show Lower Pane"
menu and the "View", "Lower Pane", "DLLs" menu. The tooltip on a dll shows its
- In the .NET Reflector Object Browser, select the
Microsoft.VisualStudio.ExtensionManager.Implementation.dll assembly and
right-click the "Enable Debugging" context menu. Click the "Done" button when the
decompilation is complete.
- In the .NET Reflector Object Browser, expand the
Microsoft.VisualStudio.ExtensionManager.Implementation.dll node and go to some
method, for example the "Microsoft.VisualStudio.ExtensionManager.UI" namespace,
"ExtensionInstallDialog" class, "InstallExtension" method and double-click it to open its
source code. Put a breakpoint on that method.
- Repeat the operation with the "Microsoft.VisualStudio.ExtensionManager"
namespace, "ExtensionManagerService" class, "InstallWorker" method.
- Click the "Debug", "Start Debugging" menu of Visual Studio to start debugging.
- Visual Studio 2010 should be launched and the breakpoints should show with an
exclamation mark during some seconds until the warning disappears, which means
that the debugged assembly is loaded and the debugger is attached.
- Go to the "Tools", "Extension Manager..." menu and install your extension. The
breakpoints should be hit at some point of the installation process.
Go back to the 'Resources for Visual Studio .NET extensibility' section for more articles like this