How to debug Visual Studio extensions

Question

I'm just writing a VSIX extension for Visual Studio 2010 and can't figure out how to debug it.

One obvious method is to output messages. Extension template uses Trace.WriteLine(). But where to find it's output?

Expiable

Answer 1

Visual Studio Extensions can be debugged like any other application. You just need to setup the debug experience to launch devenv with the loaded extension. Try the following

• Right click on the project and select Properties
• Go to the Debug Tab

Click on the radio button for Start External Program. Point it to the devenv.exe binary. On my machine it's located at

C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe

On a non x64 machine though you can remove the " (x86)" portion.

Then set the command line arguments to /rootsuffix Exp. This tells Visual Studio to use the experimental hive instead of the normal configuration hive. By default VSIX extensions when built will register themselves in the experimental hive.

Now you can F5 and it will start Visual Studio with your VSIX as an available extension.

Dissimilar

@Dissimilar - is there a way to tell vs2012 extension to register itself in the experimental hive of vs2015 preview? – Bilge

It seems that this works only if the versions you use to debug and to test are the same. So you can't debug in 2013 and run the extension in 2015. @SrikanthVenugopalan – Abrahamsen

@miparnisari - yes, so it seems. Kind of a pain though, if you are supporting multiple versions. – Bilge

Thank you. Somehow the /rootsuffix Exp got lost from my config and nothing worked. – Ricci

Hi, what do you mean it will start VS with my VSIX as an "available extension"? Where do I find the available extensions? When I go to Tools -> Extensions and Updates, I only see "Installed", "Online" and "Updates". – Paleoasiatic

Answer 2

The accepted answer by @JaredPar is technically correct, but suffers from the fact that you need to redo it for every developer, every time you get a fresh copy of the code, and any time the csproj.user file is deleted. When you do it that way, the settings are saved in the csproj.user file.

A better option is to put the settings in the csproj file so they are not lost. Unfortunately, Visual Studio does not allow you to do this automatically, so you need to manually add the settings. Luckily, the settings are the same for any project.

Right-click and unload the project, then right click again and edit the csproj project file file. In the XML, add the following to the first PropertyGroup, for example right after TargetFramework.

<StartAction>Program</StartAction>
<StartProgram>$(DevEnvDir)\devenv.exe</StartProgram>
<StartArguments>/rootsuffix Exp</StartArguments>

This has the following advantages;

• It sets it up for debug and release
• It runs whatever version of Visual Studio you are currently running
• It is checked into source control, so every developer doesn't have to remember how to do it :)

As @MBulli states in the comments, if you have made the changes in the accepted answer, delete your *.csproj.user file because the settings in it will override the ones you added to the main csproj file.

Warmedover

Make sure to delete the *.csproj.user file because the user settings have precedence over the project settings. – Trilby

Worked perfectly for vs 2019 – Daphinedaphna

Answer 3

The OutputWindowHelper.OutputString method writes to the 'General' output window pane (Ctrl Alt o). I added this line in my .csproj references to get this in VS 2013

<Reference Include="Microsoft.VisualStudio.Services.Integration, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" />

Also see this answer.

Revkah

Note OutputWindowHelper does not exist in Visual Studio 2015. A machine with only VS2015 will throw an error if this is called. See also github.com/landofjoe/NuspecPackager/issues/1 – Rennet

Answer 4

If you try to debug a UnitTestExtension, you should also attach the debugger to the vstest.*.exe processes like descibed here. Otherwise you might see the activate breakpoint but the debugger will never hit it.

Ey