native_toolchain_c fails when SQL Server Management Studio is installed — vswhere -latest returns SSMS instead of Visual Studio

native_toolchain_c calls vswhere.exe -format json -utf8 -latest -products * to locate a Visual Studio installation with a C++ compiler.
However, when SQL Server Management Studio (SSMS) 22 is installed, vswhere returns SSMS instead of Visual Studio, because SSMS reports a version number of 22.x — which is numerically higher than Visual Studio 2022 (17.x) or even Visual Studio 2026 (18.x).

Since SSMS does not contain a C/C++ compiler, the build fails with:

No compiler configured on host 'windows_x64' with target 'windows_x64'.

Steps to reproduce

Install SQL Server Management Studio 22 (any edition)
Install Visual Studio 2022 or later with the Desktop development with C++ workload
Run any Flutter project that depends on native_toolchain_c (e.g. via win32) (for example by using build_runner)

Expected behavior

A Visual Studio installation containing Microsoft.VisualStudio.Component.VC.Tools.x86.x64 is detected and used.

Actual behavior

vswhere -latest -products * returns SSMS 22 (22.5.11709.299) — which has the highest version number on the system but contains no C++ toolchain:

{
  "installationName": "SSMS/22.5.0+11709.299",
  "installationPath": "C:\\Program Files\\Microsoft SQL Server Management Studio 22\\Release",
  "installationVersion": "22.5.11709.299",
  "productId": "Microsoft.VisualStudio.Product.Ssms",
  "displayName": "SQL Server Management Studio 22"
}

Root cause

The -latest flag in vswhere sorts purely by installationVersion. SSMS uses a version scheme (22.x) that sorts higher than any current Visual Studio release (17.x, 18.x), causing it to win the -latest selection even though it is not a compiler host.

Proposed fix

Add -requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64 to the vswhere invocation. This filters results to installations that actually contain the x86/x64 C++ build tools, regardless of version ordering. Verified output with this flag:

{
  "installationName": "VisualStudio/18.5.1+11716.220",
  "installationPath": "C:\\Program Files\\Microsoft Visual Studio\\18\\Community",
  "installationVersion": "18.5.11716.220",
  "productId": "Microsoft.VisualStudio.Product.Community",
  "displayName": "Visual Studio Community 2026"
}

The corrected call would be:

vswhere.exe -format json -utf8 -latest -products * -requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64

native/pkgs/native_toolchain_c/lib/src/native_toolchain/msvc.dart

Lines 259 to 276 in a49feb0

    
           class VisualStudioResolver implements ToolResolver { 
        
             @override 
        
             Future<List<ToolInstance>> resolve(ToolResolvingContext context) async { 
        
               final vswhereInstances = await vswhere.defaultResolver!.resolve(context); 
        
               final logger = context.logger; 
        
               final result = <ToolInstance>[]; 
        
               for (final vswhereInstance in vswhereInstances.take(1)) { 
        
                 final vswhereResult = await runProcess( 
        
                   executable: vswhereInstance.uri, 
        
                   arguments: ['-format', 'json', '-utf8', '-latest', '-products', '*'], 
        
                   logger: logger, 
        
                 ); 
        
                 final instances = parseVswhere(vswhereResult.stdout, logger); 
        
                 result.addAll(instances); 
        
               } 
        
               return result; 
        
             }

Workaround

Until fixed: uninstall SSMS 22, or manually set the CC/compiler environment variables to bypass vswhere detection.

Environment

native_toolchain_c (via win32 hook)
Windows 11
SSMS 22.5.0 installed
Visual Studio Community 2026 (18.5.1) with C++ workload installed
vswhere.exe from C:\Program Files (x86)\Microsoft Visual Studio\Installer\

Possibly related:

Windows build fails when Visual Studio is installed in default path (spaces in Program Files) #3321 (comment)

@Chaos02

Thanks for the report and PR @Chaos02! 🙏

Add -requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64

What about Windows on ARM 64? What is the right string for ARM 64? And do we need to check the host architecture? Or is this requires parameter talking about the target architecture?

@Chaos02

Thanks for the report and PR @Chaos02! 🙏

Add -requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64

What about Windows on ARM 64? What is the right string for ARM 64? And do we need to check the host architecture? Or is this requires parameter talking about the target architecture?

Ohh really good point! Haven't thought about arm!
This Problem popped up for me because I needed to run dart code on my machine So I think it's the target architecture.

Since Windows on arm can immediately run x86 and amd64 compiles, this is not a big issue but supporting arm64 natively should be possible.
I don't have a device to test this on (and no idea how to emulate an arm device) but I believe that trying to resolve for Microsoft.VisualStudio.Component.VC.Tools.arm64 first before falling back to x86.x64 would solve that.

The -requires flag does it resolve for the host or target architecture?

After trying to answer your question with proof, it becomes apparent to me how badly this situation is documented...

Excerpt from vswhere -? :

-requires arg One or more workload or component IDs required when finding instances.
All specified IDs must be installed unless -requiresAny is specified.
You can specify wildcards including "?" to match any one character,
or "*" to match zero or more of any characters.
See https://aka.ms/vs/workloads for a list of workload and component IDs.
-requiresAny Find instances with any one or more workload or components IDs passed to -requires.

Only Mention in their Wiki:
https://github.com/microsoft/vswhere/wiki#examples

Related Source Code:
https://github.com/microsoft/vswhere/blob/23584d45d3cfc0a6b25fe78fdd39cf8e001e817b/src/vswhere.lib/CommandArgs.cpp#L320

So going from that, it just resolves the VS Package ID, doesn't do any other resolving internally.
Lets look at how the package IDs are made up:
ohhh good, event less documentation

Microsoft.VisualStudio.Component.VC.Tools.x86.x64 is the MSVC C++ toolset (compiler/linker/headers/libs) that supports building x86 and x64 binaries so to answer your question:
TARGET Architecture

IMPLICIT Sources for this statement (Never actually mentioned explicitly, somehow):

[native_toolchain_c] Fix #3327 native_toolchain_c vswhere selection (#…

Navigation Menu

Repository navigation

native_toolchain_c fails when SQL Server Management Studio is installed — vswhere -latest returns SSMS instead of Visual Studio #3327

Steps to reproduce

Expected behavior

Actual behavior

Root cause

Proposed fix

Workaround

Environment

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	class VisualStudioResolver implements ToolResolver {
	@override
	Future<List<ToolInstance>> resolve(ToolResolvingContext context) async {
	final vswhereInstances = await vswhere.defaultResolver!.resolve(context);
	final logger = context.logger;

	final result = <ToolInstance>[];
	for (final vswhereInstance in vswhereInstances.take(1)) {
	final vswhereResult = await runProcess(
	executable: vswhereInstance.uri,
	arguments: ['-format', 'json', '-utf8', '-latest', '-products', '*'],
	logger: logger,
	);
	final instances = parseVswhere(vswhereResult.stdout, logger);
	result.addAll(instances);
	}
	return result;
	}

native_toolchain_c fails when SQL Server Management Studio is installed — vswhere -latest returns SSMS instead of Visual Studio #3327

Description

Steps to reproduce

Expected behavior

Actual behavior

Root cause

Proposed fix

Workaround

Environment

Activity

dcharkes commented on Apr 24, 2026

Chaos02 commented on Apr 24, 2026

dcharkes commented on Apr 24, 2026

Chaos02 commented on Apr 28, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions