FAQ

The following are frequently-asked questions. Please review before opening a new issue.

Why can't I just use registry keys to find Visual Studio?

Visual Studio 2017 introduced a number of changes including multi-instancing to support installing release and preview channels on the same machine. This lets customers try new features and changes in preview versions of Visual Studio with minimal impact to stable versions other team members may be using.

Installer engines like Windows Installer or chainers like Burn do not support enumerating registry keys or values in a way that can be used to retarget installation directories without custom actions or custom bootstrapper applications. This also provides an opportunity to support querying for what workloads and components are installed without overly populating the registry, which does affect overall Windows performance.

Even if we provided custom actions to query the registry or other stores, most installers do not handle installing the same components to multiple directories. Which instance do we choose by default? How do users install to other instances (Windows Installer doesn't make this easy)? What if an installer is running silently without interaction and, therefore, cannot prompt the user for their choice?

We understand this is a significant change, which is why we have worked with various communities to develop tools like vswhere and published examples to help guide developers through these changes.

Why doesn't vswhere find Visual Studio Build Tools?

vswhere was originally designed to find installations of the Visual Studio 2017 IDE, including the Community, Professional, and Enterprise editions. Traditionally, these editions have more build and test workloads than Build Tools or other editions supported by the new installer. You can still use vswhere to include Build Tools in its search using the -products parameter:

vswhere -products *

See our examples for practical uses to, for example, find MSBuild.