As I explained in the post Some implications of the new modular setup of Visual Studio 2017 for VSX developers, Visual Studio 2017 introduces among others two significant changes compared to Visual Studio 2015:

• It allows several Visual Studio editions (Community, Professional, Enterprise) to coexist at the same time on the same machine. For VSX developers, this means that Visual Studio 2017 installations now use different folders on disk, and instance Ids.
• It uses its own private registry. This post is about this.

From Visual Studio .NET 2002 to Visual Studio 2008, Visual Studio used two registry keys:

• HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\<version>: this per-machine entry was created when Visual Studio was installed (which required admin rights) and 3rd party extensions could add registry entries to it (to register packages or DDEX providers, etc.) because it was never deleted (otherwise Visual Studio would become unusable and would require reinstallation).
• HKEY_CURRENT_USER\SOFTWARE\Microsoft\VisualStudio\<version>: this per-user entry was created the first time Visual Studio was launched for a user account, and contained per-user settings. It was never deleted (otherwise user settings would be lost).

This worked fine for a few years, until Microsoft wanted Visual Studio not to require admin rights to run or even to install 3rd party extensions, and to allow file-based registration of such extensions using .pkgdef files. So, a third registry key was introduced:

• HKEY_CURRENT_USER\SOFTWARE\Microsoft\VisualStudio\<version>_Config

1. The per-machine Registry configuration, HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\<version>
2. Per-user and per-machine .pkgdef files on disk.

So, from time to time, Visual Studio 2010 copied to a per-user configuration the per-machine configuration (source #1) along with per-machine and per-user .pkgdef files on disk (source #2). This process happened when Visual Studio was launched for the first time on a user account, after a change of configuration, etc. And for this to work, at run-time the devenv.exe process redirects  HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\<version> to HKEY_CURRENT_USER\SOFTWARE\Microsoft\VisualStudio\<version>_Config.

All that means that 3rd party setups of extensions shouldn’t write directly to the HKEY_CURRENT_USER\SOFTWARE\Microsoft\VisualStudio\<version>_Config key, because it could be deleted and created again at any time. Instead, setups should either write directly to HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\<version> (which requires admin rights), to HKEY_CURRENT_USER\SOFTWARE\Microsoft\VisualStudio\<version> (which doesn’t require admin rights), or, better yet, avoid completely writing to the registry and use instead .pkgdef files on disk, either on per-machine folders (which requires admin rights) or on per-user folders (which doesn’t require admin rights).

So far so good, but now Visual Studio 2017 stops using those three registry keys and it uses its own private registry. This is a file named privateregistry.bin which is located in the (hidden) folder C:\Users\<user>\AppData\Local\Microsoft\VisualStudio\<version>_<instance-id>, where <version> is 15.0 and <instance-id> is a random value determined when each Visual Studio 2017 edition is installed:

If you want to use regedit.exe to load that private registry, follow the steps detailed in How to examine Visual Studio 2017 registry. You will end seeing this:

At this point you should be aware of all this in Visual Studio 2017:

• The private registry (privateregistry.bin file) is per-user, not per-machine. As such, it is not created when Visual Studio is installed, but when Visual Studio is launched for the first time for a user account.
• The private registry provides two keys: 15.0_<instance-id> and 15.0_<instance-id>_Config.
• The key 15.0_<instance-id> is equivalent to HKEY_CURRENT_USER\SOFTWARE\Microsoft\VisualStudio\<version> in previous versions. As such, it is never deleted (otherwise a user would lose her per-user configuration).
• The key 15.0_<instance-id>_Config is equivalent to HKEY_CURRENT_USER\SOFTWARE\Microsoft\VisualStudio\<version>_Config in previous versions. As such, it can be deleted and recreated by Visual Studio when it needs to update the configuration.
• There is no per-machine private registry. So, there is no equivalent of HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\15.0 (well, such key exists, but it stores minimal settings). The installation of Visual Studio 2017 uses exclusively per-machine .pkgdef files instead that are scanned when Visual Studio is loaded for the first time for a user account to create the key 15.0_<instance-id>_Config in the per-user private registry.
• At run-time, the devenv.exe process of Visual Studio 2017 redirects registry operations on Visual Studio keys to the privateregistry.bin file. So, this change is transparent for extensions (DLLs) that run in the devenv.exe process. Setups (which are external processes) are not so lucky. While they could use the RegLoadAppKey function to write to the 15.0_<instance-id> key for per-user extensions (never for 15.0_<instance-id>_Config, which would be overwritten later), it is much better to switch to .pkgdef files on disk (either per-machine, or per-user). If you really need to mess with the Visual Studio setup, then see Microsoft/vs-setup-samples.