Creating and running environments

In most cases, developers do not need to work with Visual Studio in the sandbox. At the same time the sandbox can be quite large and stable. Usually all the environment and additions to the studio are in a single copy. The fact that the studio is launched in several instances does not count. The environment and settings for them are the same.

However, there are a number of tasks when it is necessary to get “a studio that seems to have just been established.” What are these tasks?

• Testing add-ons for Visual Studio. You can do reviews on add-ons, or you want to see the stability of the add-on without installing it in your working studio copy.
  
• Development of add-ons for Visual Studio. In this case, it is still more dangerous for development, as an addition with errors can permanently disable the studio. But in this case, you will be insured, since for debug the studio will be launched in the sandbox.
  
• Work with very different settings for several projects. It can be various plugins, window settings, hotkeys, and generally everything that can be configured in the studio.
  

')


It took me in the light of testing the add-on to the studio, which should be installed on individual environments / profiles. Some details about the specifics of the problem: There is a framework that is put in the form of a VSIX package. The nuance is that the framework is simultaneously evolving \ supported for several numbered versions that cannot coexist in parallel within the same Visual Studio profile.

The solution for this situation would be to use Visual Studio Hives. Using this technology / approach, a situation will arise, as if you have several independent instances of Visual Studio installed in parallel. Each such instance will be named. Actually, by the name you will contact him in the future.

Creating a new studio profile is very simple and is done in one line. The same line launches the newly created Visual Studio named profile.

% PATH_TO_VS% \ devenv.exe / rootsuffix% NAME%

For example, you can create an instance named Test. Then it will look something like this:

"C: \ Program Files (x86) \ Microsoft Visual Studio 12.0 \ Common7 \ IDE \ devenv.exe" / rootsuffix Test

Creating a new named environment takes some time and when you first start you will see the studio preparation process when you first start. After that, you will have VS without a history of projects, without additions. Actually clean studio. In order to run the newly created environment, you must use the same command line.

"C: \ Program Files (x86) \ Microsoft Visual Studio 12.0 \ Common7 \ IDE \ devenv.exe" / rootsuffix Test

All environment settings will be contained in the folder. You can directly enter:

% LOCALAPPDATA% \ Microsoft \ VisualStudio

And also in the registry branch

HKCU \ Software \ Microsoft \ VisualStudio \ 12.0 Profile Name

On my home system there are 2 additional environments besides the “default”.



It:

• 12.0 - default environment
• Exp - custom
• Roslyn - custom

Install Extensions

We could stop at this, but there is a problem that could nullify all the advantages of independent environments. This problem: Inability to specify in which environment to install the VSIX package.

In the sense of there is no official way for third-party packages. In those that you are developing, configuration files will be corrected to run in a different profile. Studio extension packs do not have any keys that can help install the extension in a specific named environment. In the installation process, there is also no choice of environment. You will not be able to install the extension by dragging it into the studio window. By default everything is installed in the main studio copy.

To solve this problem, I found a small command-line tool that allows you to install VSIX into the desired Visual Studio profile. You can download it ready-made or as a code .
Using the tool is quite simple. Start the command line, specify the path to the tool, specify the studio version, the profile name, the path to the vsix package:

Root-VSIX [<VS version>] <RootSuffix> <Path to VSIX>

For example:

C: \ Tools \ Root-VSIX.exe 12.0 Test c: \ VS12 \ Extensions \ SomeExtension.vsix

All is ready!

Identification of a running profile may be a problem, since its name is not displayed anywhere in the running studio. You can distinguish the path from TaskManager or try to find or write an extension for the studio;)