Mummy's blog
As Mother Made It – Mario Majčica's web log
Resetting the Visual Studio Experimental instance
Recently, I got into developing a couple of extensions for Visual Studio. As many of you know, once you create Visual Studio Package project (or any VSIX project), by default your application will be set to start debugging in a Visual Studio Experimental instance.
To safeguard your Visual Studio development environment from untested extensions that might change it, the Visual Studio provides an alternative Visual Studio instance that you can use to experiment. You are going to develop new extensions by using Visual Studio as usual, but you will run them by using this experimental instance.
This behavior is set as default by the Visual Studio Package project template and you can see it the following screenshot:
As you can see, we are pointing to the Visual Studio executable (we can vary that parameter for testing our extension with different versions of Visual Studio) and we are passing the following command line arguments to it:
This is sufficient to start Visual Studio in Experimental instance mode and once you hit F5 and start debugging you will notice that the started instace of visual studio in the application title bar contains the “Experimental Instance” suffix.
The default location of the experimental instance depends on the Visual Studio version number. For example, for Visual Studio 2013, the location is
All the files in the directory location are considered part of that instance. Any additional experimental instances will not be loaded by Visual Studio unless the directory name is changed to the default location.
Till here all fine, but what happens once you have “ruined” your experimental instance environment? Well, you will need to reset it. Although you can find all of this information on MSDN, it isn’t linked or clear enough on how to proceed.
folder you will find a utility called CreateExpInstance. Open your command prompt and position yourself in just mentioned directory (this is the default path for Visual Studio 2013 SDK, the same applies also for Visual Studio 2012, just change your path accordingly).
All you need to do now is to execute the following command
Once the cleanup is performed, the next experimental instance you lunch will found itself in a clean environment. In case you are working with Visual Studio 2012 change the VSInstance parameter to 11.0.
You can find more details about the CreateExpInstance Utility here .
By Mario Majcica
Related post, building visual studio projects with devenv.com, deploy ssis packages from tfs/vsts build/release, using global application host file in visual studio 2015+, 2 thoughts on “resetting the visual studio experimental instance”.
[…] write more about this argument. In case of debugging problems you can check one of my previous post Resetting the Visual Studio Experimental instance. If any do not hesitate to […]
[…] Resetting the Visual Studio Experimental instance […]
Leave a Reply Cancel reply
Your email address will not be published. Required fields are marked *
Save my name, email, and website in this browser for the next time I comment.
Signing Git Commits
Starting a tfs release via rest api, azure devops extension for xl deploy.
Instantly share code, notes, and snippets.
Diagonactic / ResetExperimentalInstance.ps1
- Download ZIP
- Star ( 0 ) 0 You must be signed in to star a gist
- Fork ( 0 ) 0 You must be signed in to fork a gist
- Embed Embed this gist in your website.
- Share Copy sharable link for this gist.
- Clone via HTTPS Clone using the web URL.
- Learn more about clone URLs
- Save Diagonactic/7e8aaeba8159621b87d2d42bcaa07190 to your computer and use it in GitHub Desktop.
| <# | |
| .SYNOPSIS | |
| Resets (or creates with confirmation) the Visual Studio Experimental Instance | |
| .DESCRIPTION | |
| Given the parameters provided, will reset or create (if confirmation is given) the Experimental Instance used for Visual Studio Extensions Development located at the given InstanceName | |
| for the given Version of Visual Studio. If the instance isn't found, you'll be prompted to confirm whether or not you want to create a new instance and the existing instances will | |
| be listed to assist you in case you simply mistyped (or in the case of Visual Studio 2017, discovered that it had a hash in front of it). | |
| .PARAMETER InstanceName | |
| The name of the instance to reset (defined by the RootSuffix parameter, but may vary slightly for Visual Studio 2017). In Visual Studio 2017, this name will sometimes (always?) have a | |
| hash value in front of it | |
| .PARAMETER Version | |
| The "internal version" of Microsoft Visual Studio (15.0 = 2017, 14.0 = 2015, etc) to reset the instance on. | |
| #> | |
| param( | |
| [Parameter(Mandatory=$false, Position=0)][string]$InstanceName, | |
| [Parameter(Mandatory=$false, Position=1)][string]$Version | |
| ) | |
| function Get-VisualStudioVersions { | |
| [OutputType([string[]])] | |
| param() | |
| process { | |
| Write-Host "$($retVal.Count)..." | |
| return $retVal.ToArray() | |
| } | |
| } | |
| if ([string]::IsNullOrWhiteSpace($Version)) { | |
| # Attempt to get the version of Visual Studio that's installed, assuming there's only one | |
| $Local:Versions = New-Object System.Collections.Generic.List[string] | |
| foreach($item in (Get-Item 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\SxS\VS7' | Select-Object -Property Property).Property) { | |
| $Local:Versions.Add($item) | |
| } | |
| if ($Local:Versions.Count -eq 0) { | |
| Write-Error 'There were no Microsoft Visual Studio versions detected on this machine.' | |
| exit | |
| } | |
| if ($Versions.Count -gt 1) { | |
| Write-Host $Versions.Length | |
| Write-Host "There were $($Versions.Length) versions of Microsoft Visual Studio installed on this machine." -ForegroundColor 'Red' | |
| Write-Host "Which Version would you like to reset for?" -ForegroundColor "White" | |
| $options = New-Object Collections.ObjectModel.Collection[Management.Automation.Host.ChoiceDescription] | |
| $choices = New-Object System.Collections.Generic.List[string] | |
| $i=0; | |
| foreach($detectedVersion in $Versions) { | |
| $choices.Add($detectedVersion) | |
| $i += 1 | |
| $options.Add((New-Object Management.Automation.Host.ChoiceDescription -ArgumentList "&$i. $detectedVersion")) | |
| Write-Host "$i) $detectedVersion" | |
| } | |
| $options.Add((New-Object Management.Automation.Host.ChoiceDescription -ArgumentList "&C. Cancel")) | |
| $decision = $Host.UI.PromptForChoice("Version Selection", "Select a Version", $options, 1) | |
| if (($decision -gt $choices.Count) -or ($decision -lt 0)) { | |
| Write-Error "Cancelled." | |
| exit | |
| } | |
| $Version = $choices[$decision] | |
| } | |
| else { | |
| Write-Host $Versions | |
| Write-Warning "Auto-selecting version $Local:Versions" | |
| $Version = $Local:Versions | |
| } | |
| } | |
| $InstallPath = "$((Get-ItemProperty 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\SxS\VS7' | Select-Object $Version).$Version)" | |
| $CreateExperimentalInstance = [System.IO.Path]::Combine($InstallPath, "VSSDK\VisualStudioIntegration\Tools\Bin\CreateExpInstance.exe") | |
| if (-not (Test-Path $CreateExperimentalInstance -PathType Leaf)) { | |
| Write-Warning "Couldn't find CreateExpInstance.exe at $CreateExperimentalInstance" | |
| Write-Warning "Make sure you have the Visual Studio SDK Installed" | |
| exit | |
| } | |
| # Get the location where Visual Studio Profiles are stored | |
| $VisualStudioInstancePath = [System.IO.Path]::Combine($env:LOCALAPPDATA, "Microsoft\VisualStudio") | |
| Write-Verbose "Looking in instance path: $VisualStudioInstancePath" | |
| if (-not (Test-Path $VisualStudioInstancePath -PathType Container)) { | |
| Write-Error "Couldn't locate the path for the Visual Studio profiles. Expected path was: '$VisualStudioInstancePath'" | |
| exit | |
| } | |
| if ([string]::IsNullOrWhiteSpace($InstanceName)) { | |
| Write-Host "No Experimental Instance was Specified - Select an instance to use and set it as the first parameter of this script" | |
| Get-ChildItem $VisualStudioInstancePath | |
| exit | |
| } | |
| $ExperimentalInstancePath = [System.IO.Path]::Combine($VisualStudioInstancePath, "${Version}$InstanceName") | |
| Write-Verbose "Looking in instance path: $ExperimentalInstancePath" | |
| if (-not (Test-Path $ExperimentalInstancePath -PathType Container)) { | |
| # We'll do one extra check for the "_" version of the path since user input might have been wrong with the way VS2017 handles it | |
| $ExperimentalInstancePath = [System.IO.Path]::Combine($VisualStudioInstancePath, "${Version}_$InstanceName") | |
| $Local:OldInstanceName = $InstanceName | |
| $InstanceName = "_$InstanceName" | |
| Write-Verbose "Also checking instance path: $ExperimentalInstancePath" | |
| if (-not (Test-Path $ExperimentalInstancePath -PathType Container)) { | |
| # Reset it back to the original name the user provided since we couldn't find eiher | |
| $ExperimentalInstancePath = [System.IO.Path]::Combine($VisualStudioInstancePath, "${Version}$InstanceName") | |
| $InstanceName = $Local:OldInstanceName | |
| $Instances = (Get-ChildItem $VisualStudioInstancePath ${Version}*) | |
| if ($Instances.Length -eq 0) { | |
| Write-Error "Couldn't find a Visual Studio profile for Microsoft Visual Studio $Version in '$VisualStudioInstancePath'" | |
| exit | |
| } | |
| Write-Host "The Microsoft Visual Studio $Version experimental instance named '$InstanceName' was not found, however, others were:" | |
| foreach($existingInstance in $Instances) { | |
| Write-Host "$existingInstance" | |
| } | |
| $options = New-Object Collections.ObjectModel.Collection[Management.Automation.Host.ChoiceDescription] | |
| $options.Add((New-Object Management.Automation.Host.ChoiceDescription -ArgumentList '&Yes')) | |
| $options.Add((New-Object Management.Automation.Host.ChoiceDescription -ArgumentList '&No')) | |
| $decision = $Host.UI.PromptForChoice("Instance Doesn't Exist", "Resetting the instance named '$InstanceName' will create a new experimental instance. Are you sure you want to do that?", $options, 1) | |
| if ($decision -ne 0) { | |
| exit | |
| } | |
| } | |
| } | |
| . $CreateExperimentalInstance /Reset /VSInstance=$Version /RootSuffix=$InstanceName | |
| Write-Host "Experimental Instance for Microsoft Visual Studio $Version named '$InstanceName' was reset." |
Resetting Visual Studio Experimental Instance to its super-clean initial state
If you are doing Visual Studio extensibility (VSX) work, you are probably aware of the existence of the Visual Studio "Experimental" instance. This is basically an instance of VS that has its own isolated registry, settings, extensions, etc. This allows you to test your extensions to VS without polluting your main development environment.
Sometimes, the environment might get corrupted for whatever reason, or it might be that you just want to test your extension with a clean environment after messing with it for a while.
Read full article
No Comments
Harshit Shrivastava
Random ramblings on bits and bytes, resetting visual studio’s experimental instance to its super-clean state.
In order to create Visual Studio extensions (VSIX), one needs to download the Visual Studio SDKs (freely available) from the Microsoft’s website. Those of you doing the VSIX work are probably already aware of the Visual Studio’s “experimental” instance.
This experimental instance of Visual studio runs just like an isolated instance, having its own registry values, settings, extensions, etc. This allows testing of extensions without affecting the development environment of Visual Studio at all.
Sometimes the “experimental” instance gets corrupted, may be due to installations of some extensions, some registry values getting corrupted, or for any other reason, whatsoever. Or may be, we just want to test the extension with some custom settings and then revert back to the original clean settings.
The Visual Studio 2010, 2012 and 2013 come with a tool to reset the settings which is available from the start menu, named, “Reset the Visual Studio xxxx Experimental instance”. That does not, however, give the pristine environment that was available the first time before even testing the first extension.
To get a super clean instance, follow these steps. These are for Visual Studio 2012, but same can be followed for VS2010 and VS2013 also.
- Close all running instances of Visual Studio.
- Delete the entire folder %LocalAppData%\Microsoft\VisualStudio\11.0Exp60.
- Go to Run, type regedit and press Enter.
- Delete the registry key HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\11.0Exp60.
- Delete the registry key HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\11.0Exp60_Config.
- Run the command “Reset the Microsoft Visual Studio 2012 Experimental instance” from your start menu.
Now, the experimental instance of Visual Studio is reset to its super clean instance. If you frequently keep developing extensions, you would appreciate the install/reset experience provided by VS2010 onwards. If not, resetting does not sound that scary, does it 😉 . So without worrying about the possibility of experimental instance getting corrupted permanently, keep developing extensions. Happy extending 😀 .
Share this:
Leave a comment cancel reply.
- Already have a WordPress.com account? Log in now.
- Subscribe Subscribed
- Copy shortlink
- Report this content
- View post in Reader
- Manage subscriptions
- Collapse this bar
Matthew S. Dippel The Official Blog*
Resetting the visual studio experimental instance visual studio 2010-2017 via powershell.
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.
| Marketing Version | Actual Version | Framework Versions |
|---|---|---|
| 2010 | 10.0 | 4.0 |
| 2012 | 11.0 | 4.5.2 |
| 2013 | 12.0 | 4.5.2 |
| 2015 | 14.0 | 4.6 |
| 2017 | 15.0 | 4.6.2 |
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 to C:\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:
… or if you prefer cmd.exe :
Visual Studio 2017
Things were reorganized a little bit with Visual Studio 2017. The install root is now located at:
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:
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.
No comments :
Post a Comment
- Stay Frosty - Constructor and Method Block Highlighter, Text Clarity and Customization for Visual Studio
- Diagonactic Enums - Helper methods for C#/VB.Net Enums Truly Constrained to System.Enum (written in C++/CLI and MSIL)
Blog Archive
- ► October ( 1 )
- ► September ( 2 )
- HOWTO: Import Keybase.io Public Keys to SSH author...
- Resetting the Visual Studio Experimental Instance ...
- ► November ( 1 )
- ► September ( 1 )
- ► July ( 1 )
- ► April ( 1 )
- ► March ( 2 )
- ► February ( 4 )
- ► August ( 2 )
- ► June ( 1 )
- ► May ( 1 )
- ► February ( 2 )
- ► November ( 3 )
- ► December ( 6 )
- ► December ( 1 )
- ► January ( 1 )
- ► August ( 1 )
- ► March ( 1 )
- ► April ( 2 )
- ► July ( 3 )
- ► October ( 2 )
- ► May ( 3 )
- Latest Articles
- Top Articles
- Posting/Update Guidelines
- Article Help Forum
- View Unanswered Questions
- View All Questions
- View C# questions
- View C++ questions
- View Javascript questions
- View Visual Basic questions
- View .NET questions
- CodeProject.AI Server
- All Message Boards...
- Running a Business
- Sales / Marketing
- Collaboration / Beta Testing
- Work Issues
- Design and Architecture
- Artificial Intelligence
- Internet of Things
- ATL / WTL / STL
- Managed C++/CLI
- Objective-C and Swift
- System Admin
- Hosting and Servers
- Linux Programming
- .NET (Core and Framework)
- Visual Basic
- Web Development
- Site Bugs / Suggestions
- Spam and Abuse Watch
- Competitions
- The Insider Newsletter
- The Daily Build Newsletter
- Newsletter archive
- CodeProject Stuff
- Most Valuable Professionals
- The Lounge
- The CodeProject Blog
- Where I Am: Member Photos
- The Insider News
- The Weird & The Wonderful
- What is 'CodeProject'?
- General FAQ
- Ask a Question
- Bugs and Suggestions
Common Visual Studio Extension Woes
As a developer of a rather popular Visual Studio extension, I have often had my fair share of issues when dealing with some of the quirks involved when building an extension. 90% of the time, these issues generally center on the debugging process. This post focuses on a few of these and how to go about resolving them.
My Extension Can't Be Found
On numerous occasions, when working with Glyphfriend and adding some new features or refactoring things, I'll receive the following error message when attempting to build the application:
Extension '[Insert-Guid-Here]' could not be found. Please make sure the extension has been installed.
Although it's right there, it can't seem to be found. There are a few ways to try and troubleshoot this, which vary in rates of success.
Option 1: Reset Command Line Arguments
Visual Studio handles debugging extensions by spinning up an "experimental" instance of the IDE and basically installing your extension to the said instance so that you can play with it. If you have the previously mentioned "Extension cannot be found." error, then you may need to try resetting the arguments.
Just follow these steps:
- Right-click on your Project in the Solution Explorer.
- Choose Properties .
- Select the Debug tab on the left.
- Clear out the Command Line Arguments box.
- Build your Solution manually or via CTRL+Shift+B .
- Set the Command Line Arguments to /rootsuffix Exp .
- Rebuild the Project .
Option 2: Tinkering with the Experimental Instance
If the previous approach didn't work, then you might have to do a bit of tinkering with the experimental instance of Visual Studio as its settings may have gotten a bit out of whack.
You can try some of the following approaches to tackle that issue:
- Manually open and close an experimental instance of Visual Studio to reset its state . You can find this by searching your local machine for "Experimental".
- Update the package version of your extension in the manifest . Updating the version number can assist with breaking the experimental instance out of said funk.
- Run the Reset the Visual Studio 2015 Experimental Instance tool .
Option 3: Burninate the Folder
If those don't work, one final approach that I found success with is to explicitly clear out the Visual Studio Experimental Settings folder for your current user account. This folder should contain all of the settings for your experimental instance, which will be recreated when the instance is launched.
The folder can be found at the following location:
This fix was the most consistent in my experience, but your mileage may vary.
Debugger Issues and Symbols Not Loading...
Another point of frustration that I experienced fairly frequently was the Visual Studio debugger not properly attaching to the experimental instance or loading the symbols for the project. Either of these won't allow the debugger to attach and thus make actual debugging rather difficult.
The first thing to ensure is that you are running in a Debug configuration or that you at least have a DEBUG constant defined checked and Optimize Code unchecked within your Build Properties.
If you find that you still can't debug your application after this, consider reverting to Option 3 of the previous section and delete the Experimental Instance folder once again at the following location:
You'll need to do this each time that you launch your extension to ensure that any previous settings are changed and symbols are updated properly (or if you are handy, you could write a script to try to do this for you).
CodeProject
This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)
Comments and Discussions
| to use this message board. | ||||||||
This browser is no longer supported. Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support. Create a basic project system, part 2
The first walkthrough in this series, Create a basic project system, part 1 , shows how to create a basic project system. This walkthrough builds on the basic project system by adding a Visual Studio template, a property page, and other features. You must complete the first walkthrough before you start this one. This walkthrough teaches how to create a project type that has the project file name extension .myproj . To complete the walkthrough, you do not have to create your own language because the walkthrough borrows from the existing Visual C# project system. This walkthrough teaches how to accomplish these tasks: Create a Visual Studio template. Deploy a Visual Studio template. Create a project type child node in the New Project dialog box. Enable parameter substitution in the Visual Studio template. Create a project property page. The steps in this walkthrough are based on a C# project. However, except for specifics such as file name extensions and code, you can use the same steps for a Visual Basic project. Create a Visual Studio template
By using a Visual Studio template ( .vstemplate file) instead of a basic project template, you can control how the template appears in the New Project dialog box and how template parameters are substituted. A .vstemplate file is an XML file that describes how source files are to be included when a project is created by using the project system template. The project system itself is built by collecting the .vstemplate file and the source files in a .zip file, and deployed by copying the .zip file to a location that is known to Visual Studio. This process is explained in more detail later in this walkthrough. In Visual Studio, open the SimpleProject solution that you created by following Create a basic project system, part 1 . In the SimpleProjectPackage.cs file, find the ProvideProjectFactory attribute. Replace the second parameter (the project name) with null, and the fourth parameter (the path to the project template folder) with ".\\NullPath", as follows. Add an XML file named SimpleProject.vstemplate to the \Templates\Projects\SimpleProject\ folder. Replace the contents of SimpleProject.vstemplate with the following code. In the Properties window, select all five files in the \Templates\Projects\SimpleProject\ folder and set the Build Action to ZipProject .  The <TemplateData> section determines the location and appearance of the SimpleProject project type in the New Project dialog box, as follows: The <Name> element names the project template to be SimpleProject Application. The <Description> element contains the description that appears in the New Project dialog box when the project template is selected. The <Icon> element specifies the icon that appears together with the SimpleProject project type. The <ProjectType> element names the Project type in the New Project dialog box. This name replaces the project name parameter of the ProvideProjectFactory attribute. The <ProjectType> element must match the LanguageVsTemplate argument of the ProvideProjectFactory attribute in the SimpleProjectPackage.cs file. The <TemplateContent> section describes these files that are generated when a new project is created: SimpleProject.myproj AssemblyInfo.cs All three files have ReplaceParameters set to true, which enables parameter substitution. The Program.cs file has OpenInEditor set to true, which causes the file to be opened in the code editor when a project is created. For more information about the elements in the Visual Studio Template schema, see the Visual Studio template schema reference . If a project has more than one Visual Studio template, every template is in a separate folder. Every file in that folder must have the Build Action set to ZipProject . Adding a minimal .vsct fileVisual Studio must be run in setup mode to recognize a new or modified Visual Studio template. Setup mode requires a .vsct file to be present. Therefore, you must add a minimal .vsct file to the project. Add an XML file named SimpleProject.vsct to the SimpleProject project. Replace the contents of the SimpleProject.vsct file with the following code. Set the Build Action of this file to VSCTCompile . You can do this only in the .csproj file, not in the Properties window. Make sure that the Build Action of this file is set to None at this point. Right-click the SimpleProject node and then click Edit SimpleProject.csproj . In the .csproj file, locate the SimpleProject.vsct item. Change the build action to VSCTCompile . the project file and close the editor. Save the SimpleProject node, and then in the Solution Explorer click Reload Project . Examine the Visual Studio template build stepsThe VSPackage project build system typically runs Visual Studio in setup mode when the .vstemplate file is changed or the project that contains the .vstemplate file is rebuilt. You can follow along by setting the verbosity level of MSBuild to Normal or higher. On the Tools menu, click Options . Expand the Projects and Solutions node, and then select Build and Run . Set MSBuild project build output verbosity to Normal . Click OK . Rebuild the SimpleProject project. The build step to create the .zip project file should resemble the following example. Deploy a Visual Studio templateVisual Studio templates do not contain path information. Therefore, the template .zip file must be deployed to a location that is known to Visual Studio. The location of the ProjectTemplates folder is typically <%LOCALAPPDATA%>\Microsoft\VisualStudio\14.0Exp\ProjectTemplates . To deploy your project factory, the installation program must have administrator privileges. It deploys templates under the Visual Studio installation node: ...\Microsoft Visual Studio 14.0\Common7\IDE\ProjectTemplates . Test a Visual Studio templateTest your project factory to see whether it creates a project hierarchy by using the Visual Studio template. Reset the Visual Studio SDK experimental instance. On Windows 7: On the Start menu, find the Microsoft Visual Studio/Microsoft Visual Studio SDK/Tools folder, and then select Reset the Microsoft Visual Studio Experimental instance . On later versions of Windows: On the Start screen, type Reset the Microsoft Visual Studio <version> Experimental Instance . A command prompt window appears. When you see the words Press any key to continue , click ENTER . After the window closes, open Visual Studio. Rebuild the SimpleProject project and start debugging. The experimental instance appears. In the experimental instance, create a SimpleProject project. In the New Project dialog box, select SimpleProject . You should see a new instance of SimpleProject.  Create a project type child nodeYou can add a child node to a project type node in the New Project dialog box. For example, for the SimpleProject project type, you could have child nodes for console applications, window applications, web applications, and so on. Child nodes are created by altering the project file and adding <OutputSubPath> children to the <ZipProject> elements. When a template is copied during build or deployment, every child node becomes a subfolder of the project templates folder. This section shows how to create a Console child node for the SimpleProject project type. Rename the \Templates\Projects\SimpleProject\ folder to \Templates\Projects\ConsoleApp\ . In the Properties window, select all five files in the \Templates\Projects\ConsoleApp\ folder and make sure the Build Action is set to ZipProject . In the SimpleProject.vstemplate file, add the following line at the end of the <TemplateData> section, just before the closing tag. This causes the Console Application template to appear both in the Console child node and in the SimpleProject parent node, which is one level above the child node. Save the SimpleProject.vstemplate file. In the .csproj file, add <OutputSubPath> to each of the ZipProject elements. Unload the project, as before, and edit the project file. Locate the <ZipProject> elements. To each <ZipProject> element, add an <OutputSubPath> element and give it the value Console. The ZipProject Add this <PropertyGroup> to the project file: Save the project file and reload the project. Test the project type child nodeTest the modified project file to see whether the Console child node appears in the New Project dialog box. Run the Reset the Microsoft Visual Studio Experimental Instance tool. Rebuild the SimpleProject project and start debugging. The experimental instance should appear In the New Project dialog, click the SimpleProject node. The Console Application template should appear in the Templates pane. Expand the SimpleProject node. The Console child node should appear. The SimpleProject Application template continues to appear in the Templates pane. Click Cancel and stop debugging.  Substitute project template parameters
When you create a project by using a Visual Studio template in the New Project dialog box, template parameters are replaced with strings to customize the project. A template parameter is a special token that begins and ends with a dollar sign, for example, $time$. The following two parameters are especially useful for enabling customization in projects that are based on the template: $GUID[1-10]$ is replaced by a new Guid. You can specify up to 10 unique GUIDs, for example, $guid1$. $safeprojectname$ is the name provided by a user in the New Project dialog box, modified to remove all unsafe characters and spaces. For a complete list of template parameters, see Template parameters . To substitute project template parametersIn the SimpleProjectNode.cs file, remove the AddFileFromTemplate method. In the \Templates\Projects\ConsoleApp\SimpleProject.myproj file, locate the <RootNamespace> property and change its value to $safeprojectname$. In the \Templates\Projects\SimpleProject\Program.cs file, replace the contents of the file with the following code: Rebuild the SimpleProject project and start debugging. The experimental instance should appear. Create a new SimpleProject Console application. (In the Project types pane, select SimpleProject . Under Visual Studio installed templates , select Console Application .) In the newly-created project, open Program.cs . It should look something like the following (GUID values in your file will differ.): Create a project property pageYou can create a property page for your project type so that users can view and change properties in projects that are based on your template. This section shows you how to create a configuration-independent property page. This basic property page uses a properties grid to display the public properties that you expose in your property page class. Derive your property page class from the SettingsPage base class. The properties grid provided by the SettingsPage class is aware of most primitive data types and knows how to display them. In addition, the SettingsPage class knows how to persist property values to the project file. The property page you create in this section lets you alter and save these project properties: AssemblyName RootNamespace. In the SimpleProjectPackage.cs file, add this ProvideObject attribute to the SimpleProjectPackage class: This registers the property page class GeneralPropertyPage with COM. In the SimpleProjectNode.cs file, add these two overridden methods to the SimpleProjectNode class: Both of these methods return an array of property page GUIDs. The GeneralPropertyPage GUID is the only element in the array, so the Property Pages dialog box will show only one page. Add a class file named GeneralPropertyPage.cs to the SimpleProject project. Replace the contents of this file by using the following code: The GeneralPropertyPage class exposes the three public properties AssemblyName, OutputType, and RootNamespace. Because AssemblyName has no set method, it is displayed as a read-only property. OutputType is an enumerated constant, so it appears as dropdown list. The SettingsPage base class provides ProjectMgr to persist the properties. The BindProperties method uses ProjectMgr to retrieve the persisted property values and set the corresponding properties. The ApplyChanges method uses ProjectMgr to get the values of the properties and persist them to the project file. The property set method sets IsDirty to true to indicate that the properties have to be persisted. Persistence occurs when you save the project or solution. Rebuild the SimpleProject solution and start debugging. The experimental instance should appear. In the experimental instance, create a new SimpleProject Application. Visual Studio calls your project factory to create a project by using the Visual Studio template. The new Program.cs file is opened in the code editor. Right-click the project node in Solution Explorer , and then click Properties . The Property Pages dialog box is displayed.  Test the project property pageNow you can test whether you can modify and change property values. In the MyConsoleApplication Property Pages dialog box, change the DefaultNamespace to MyApplication . Select the OutputType property, and then select Class Library . Click Apply , and then click OK . Reopen the Property Pages dialog box and verify that your changes have been persisted. Close the experimental instance of Visual Studio. Reopen the experimental instance.  Additional resourcesReSharper Platform SDK HelpRunning resharper in visual studio experimental instance. Visual Studio's "Experimental Instance" feature is intended for developing and debugging Visual Studio extensions, and maintains a separate copy of the configuration needed to run Visual Studio. Each experimental instance can have an entirely different configuration, from theme and window layout to the extensions that are loaded. By default, ReSharper (and the other .net tools, dotCover, dotMemory, dotTrace, etc.) are installed as per-machine Visual Studio extensions. This means that they are available to all users on the machine, but also that they are loaded in all experimental instances. The Platform layer that provides Visual Studio integration to ReSharper and the other .net tools, has support to move its registration from per-machine to per-user, and per-experimental instance. This allows for ReSharper (dotTrace, et al) to not be loaded in experimental instances, should the need arise. Moving to a per-user installReSharper will handle moving the registration from per-machine to per-user automatically. When you run ReSharper in Internal mode, ReSharper will check and prompt to move to a per-user install (this process is deferred until initialisation is complete, and may take a couple of seconds). This is not the same as moving to an experimental instance, but will instead register ReSharper to run in the default Visual Studio instance. However, once moved, it will only run in the default instance, and not run in any experimental instances. devenv.exe /ReSharper.Internal  If you click "Yes, make the extension run in this hive only", ReSharper will restart Visual Studio as admin, and move the registration files from the Visual Studio Common7\IDE\Extensions folder in Program Files to %LOCALAPPDATA%\Microsoft\VisualStudio\X.X\Extensions , where X.X is the version of Visual Studio (this is supported for Visual Studio 2010+). ReSharper will also update the HKCU\Software\Microsoft\VisualStudio\X.X\ExtensionManager\EnabledExtensions registry key to add the new location as an enabled extension. Moving to an experimental instanceMoving to an experimental instance is the same process as moving to a per-user install, except you need to be running in the experimental instance. Once you've created an experimental instance, and assuming ReSharper is still installed per-machine, run Visual Studio in the experimental instance, and with the internal flag: devenv.exe /RootSuffix MyExpInstance /ReSharper.Internal The same dialog will be displayed, and the per-machine registration moved to the experimental instance. ReSharper will now only load in the experimental instance.  If you have already moved the per-machine registration to be per-user, this technique won't work, as the per-user install only loads in the default Visual Studio instance. You need to repair the ReSharper install first, in order to restore the per-machine registration. This won't affect the per-user registration. Resetting the relocation dialogIf you uncheck the "Participate in the Experimental Hive Assistance Program" checkbox, ReSharper will no longer check for per-machine registration at startup, and will no longer display the dialog. To reset this, you need to manually edit the %ёAPPDATA%\JetBrains\ReSharper\vAny\GlobalSettingsStorage.dotSettings file (this is for advanced users, expect to get your hands dirty!). Search for the string vsix and remove any XML elements that contain it, particularly this one: The next time you restart Visual Studio with ReSharper in internal mode, ReSharper will check, and display the dialog again. Side-by-side install of multiple versionsIt is possible, although perhaps not very desirable, to have multiple versions of ReSharper or other .net tools installed side-by-side, by making use of experimental instances. First, move the current install of ReSharper to an experimental instance, as detailed above (note that versions of ReSharper prior to 8.2 had a bug that didn't update the path to the extensions folder correctly in the registry, and 7.x requires to be manually run as admin) When installing the new version of ReSharper, ensure that you select "Advanced" options in the installer, and uncheck the option to remove all previous versions After installing, move the new version of ReSharper to a per-user install, by running with the internal flag. If the dialog doesn't popup, check the GlobalSettingsStorage.dotSettings file as detailed above.
Collectives™ on Stack OverflowFind centralized, trusted content and collaborate around the technologies you use most. Q&A for work Connect and share knowledge within a single location that is structured and easy to search. Get early access and see previews of new features. Visual Studio extension does not load in experimental instanceI'm developing a Visual Studio extension in VS2013 but I can get it to load in the experimental instance. I can install it manually in my current instance (from the vsix file) and it works fine but I am unable to debug it. There are no error messages nor anything in the ActivityLog. My extension just isn't loaded. (It is not just my extension. The same thing happens with a fresh extension from the project template) I have tried to delete/reset the experimental instance without luck. I also tried to debug my extension by creating the experimental instance from my current instance with my extension installed. The extension then showed up as "Disabled" in "Extensions and updates" in the experimental instance. Tried to search for how the extension registration is performed in the experimental instance but could not find anything. Only found refrences to the setting "Deploy VSIX content to experimental instance for debugging" but not anything about what the setting does. Currently my testing work liks this:
which of course takes a long time.
 2 Answers 2This is probably a duplicate question. Just check the Debug options of your VSIX project. This answer might help: Cannot run VSPackage when developing on multiple machines If the automatic registration of your extension works, you should find entries with your package-id in the registry under the following keys: 
You need to enable the installed extension from Extension manager. It'd ask for a IDE restart, and it should be all set up  Your AnswerReminder: Answers generated by artificial intelligence tools are not allowed on Stack Overflow. Learn more Sign up or log inPost as a guest. Required, but never shown By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy . Not the answer you're looking for? Browse other questions tagged visual-studio-2013 visual-studio-extensions vsix vspackage or ask your own question .
Hot Network Questions
| ||||||||
IMAGES
VIDEO
COMMENTS
One key point of VS extension development is to reset experimental instance of Visual Studio, which I am having problem with. ... The Visual Studio Experimental instance directory C:\Users\Mi\AppData\Local\Microsoft\VisualStudio\10.0Exp does not exist. CreateExpInstance: warning : The Visual Studio directory C:\Users\Mi\AppData\Local\Microsoft ...
To safeguard your Visual Studio development environment from untested applications that might change it, the VSSDK provides an experimental space that you can use to experiment. You develop new applications by using Visual Studio as usual, but you run them by using this experimental instance.
Resetting the Experimental Instance. Inside the C:\Program Files (x86)\Microsoft Visual Studio 12.0\VSSDK\VisualStudioIntegration\Tools\Bin folder, you will find a utility called CreateExpInstance. Open your command prompt and position yourself in just mentioned directory (this is the default path for Visual Studio 2013 SDK, the same applies ...
When you are working on a Visual Studio extension, you can press F5 to open the default experimental instance and install the current extension. If no experimental instance is available, Visual Studio creates one that has the default settings. The default location of the experimental instance depends on the Visual Studio version number.
It's called Reset the Visual Studio Experimental Instance, and it ships as part of the Visual Studio SDK. This script removes all references to your extensions from the experimental environment, so you can start from scratch. You can get to this script in one of two ways: From the desktop, find Reset the Visual Studio Experimental Instance.
Parameters /Reset Deletes the experimental instance, and then creates a new one. What does reset do? Once the reset is performed, the next experimental instance you launch will find itself in a clean environment. Since you are unable to load Experimental Instance, please check the following to see if the issue persists.
Reset and Clean Visual Studio Experimental Instance; Reset Exp Instance. In Visual Studio's top menu under Tools, a new command is now visible: Clicking the Reset Experimental Instance button will prompt you to confirm the resetting process. The progress of the resetting process. When it finishes, the progress form will close.
This is sufficient to start Visual Studio in Experimental instance mode and once you hit F5 and start debugging you will notice that the started instace of visual studio in the application title bar contains the "Experimental Instance" suffix. The default location of the experimental instance depends on the Visual Studio version number.
Resets (or creates with confirmation) the Visual Studio Experimental Instance.DESCRIPTION: Given the parameters provided, will reset or create (if confirmation is given) the Experimental Instance used for Visual Studio Extensions Development located at the given InstanceName: for the given Version of Visual Studio.
The Visual Studio SDK does come with a tool to reset the experimental instance, available from your Start menu with the name "Reset the Microsoft Visual Studio 2010 Experimental instance". That will not, however, give you the pristine environment you got the first time you start the experimental instance to test your first extension. ...
The Visual Studio 2010, 2012 and 2013 come with a tool to reset the settings which is available from the start menu, named, "Reset the Visual Studio xxxx Experimental instance". That does not, however, give the pristine environment that was available the first time before even testing the first extension.
Unregister an extension. If you have been experimenting with a lot of different VSPackages and want to remove them from the experimental instance, you can just run the Reset command. Look for Reset the Visual Studio Experimental Instance on the start page of your computer, or run this command from the command line: Windows Command Prompt. Copy ...
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).
In developing some extensions I grew increasing tired of having to manually reset the experimental instance of Visual Studio. You typically do this by deleting the required files in the AppData directory as well as the "Exp" key in the registry. ... Having to do this multiple times during some testing I wrote an extension and open sourced ...
Run the Reset the Visual Studio 2015 Experimental Instance tool. Option 3: Burninate the Folder. If those don't work, one final approach that I found success with is to explicitly clear out the Visual Studio Experimental Settings folder for your current user account. This folder should contain all of the settings for your experimental instance ...
Reset experimental instance of Visual Studio 2015/2017 #2583. FeodorFitsner opened this issue Aug 27, 2018 · 2 comments Labels. Visual Studio 2015 Visual Studio 2017. Milestone. images-update-201... Comments. Copy link Member. FeodorFitsner commented Aug 27, 2018.
Reset the Visual Studio SDK experimental instance. On Windows 7: ... On later versions of Windows: On the Start screen, type Reset the Microsoft Visual Studio <version> Experimental Instance. A command prompt window appears. When you see the words Press any key to continue, click ENTER. After the window closes, open Visual Studio.
If you are developing multiple extensions, or just exploring outcomes with different versions of your extension code, your experimental environment may stop working the way it should. In this case, you should run the reset script. It's called Reset the Visual Studio Experimental Instance, and it ships as part of the Visual Studio SDK.
This topic relates to ReSharper 8, and has not been updated to ReSharper 9 or the ReSharper Platform. Visual Studio's "Experimental Instance" feature is intended for developing and debugging Visual Studio extensions, and maintains a separate copy of the configuration needed to run Visual Studio. Each experimental instance can have an entirely different configuration, from theme and window ...
Currently my testing work liks this: Put in MessageBox and/or WriteLine and compile the code. Remove the previous instance of the extension in "Extensions and updates". Close Visual Studio. Install the extension from the vsix file. Start Visual Studio. Test the extension. which of course takes a long time. visual-studio-2013.