There’s a handful of things that you have to do frequently enough when debugging a Visual Studio extension that it becomes almost routine, but not frequently enough for you to actually remember the exact shape of the command you need to run.

Since I got horribly tired of having to hit up Bing every time I needed to remember the specific command, I decided to document some of them here.

The TL;DR; - Use PowerShell to Reset the Visual Studio Experimental Instance

I’ve created a simple script to reset the Visual Studio instance, available here. It takes two parameters, -Version and -InstanceName (which matches the “RootSuffix” parameter used … most of the time). You needn’t run it from a Developer Command Prompt, it grabs the install locations from the registry.

Some Useful Bits to Remember

Visual Studio Version Mapping and .Net Framework

Default Visual Studio Paths

For these defaults, I’m assuming you’re on a 64-bit operating system. If you’re still stuck banging rocks together on a 32-bit OS, just knock out the (x86) where you see it.

Visual Studio 2010 - 2015

The paths for these versions have been pretty predictable. They start in %ProgramFiles(x86)%, which usually maps toC:\Program Files (x86) and are stored in Microsoft Visual Studio 1x.x where x corresponds to one of version numbers in the Actual column.

Install Root:

"${env:ProgramFiles(x86)}\Microsoft Visual Studio 1x.x"

… or if you prefer cmd.exe:

"%ProgramFiles(x86)%\Microsoft Visual Studio 1x.x"

Visual Studio 2017

Things were reorganized a little bit with Visual Studio 2017. The install root is now located at:

"${env:ProgramFiles(x86)}\Microsoft Visual Studio\2017\<Edition>"

Where <Edition> is going to correspond to the edition, Community, Professional or Enterprise.

In addition, the RootSuffix, at least on my machine, is only part of the suffix name. This is a fact that Visual Studio understands, but the tool for creating/managing the experimental instances from the command prompt does not.

The PowerShell script provided above will provide you with experimental instance names if you attempt to reset one that doesn’t exist (as would happen if you provided Exp but the name was actually _70a4f204Exp

Refresh the Experimental Instance with the Script

Basic help can be found by typing Get-Help ResetExperimentalInstance.ps1 -Full, but here’s how you use it:

.\ResetExperimentalInstance.ps1 [-InstanceName] <InstanceName> [-Version <Version>]

Version - Optional - If you have only one version of Visual Studio installed. Note that this includes applications that use other versions of Visual Studio, like SQL Management Studio and System Center Configuration Manager’s management tools. If you have more than one version installed, the script will exit but will print the versions that are available.

InstanceName - Required - Usually the same as what is provided as the /RootSuffix parameter in the Debug panel within Visual Studio for your extension. However, it may actually be _[some 32-bit Hex][RootSuffix], i.e. _71af83c4Exp for the Exp instance. If a corresponding folder for that instance is not found, you’ll be given a list of all of the instances that are found for the provided version and prompted as to whether or not you want to create a new experimental instance.

The _ in the long name is required for the Visual Studio provided tool, CreateExpInstance.exe, which the script uses. However, the script will look for a folder that only differs by the starting _ and will correct your InstanceName if that’s the only difference.