Add Visual Studio 2026 support

[reflectronic]

I have tested this and it appears to work well.

Fixes https://github.com/rust-lang/cmake-rs/issues/253

[elad-solomon]

+1 waiting on this to be merged 🙏

[mamoreau-devolutions]

+1 waiting on this to be merged as well, we've all started uninstalling Visual Studio 2022 in favor of Visual Studio 2026 at our organization, and it's going to become a pain point very quickly.

[NiceBlueChai]

Hi — quick question / suggestion: for Visual Studio versions >= 17.0 (VS2022 and later), why not default to the Ninja CMake generator? Visual Studio itself defaults to Ninja for CMake projects, so preferring Ninja when the detected VS version is >= 17.0 would avoid having to update the generator list every time a new VS version is released and would make builds more consistent across developer environments. Could we change the generator selection logic to prefer "Ninja" for VS >= 17.0, and fall back to the current behavior otherwise?

[llc1123]

Hi — quick question / suggestion: for Visual Studio versions >= 17.0 (VS2022 and later), why not default to the Ninja CMake generator? Visual Studio itself defaults to Ninja for CMake projects, so preferring Ninja when the detected VS version is >= 17.0 would avoid having to update the generator list every time a new VS version is released and would make builds more consistent across developer environments. Could we change the generator selection logic to prefer "Ninja" for VS >= 17.0, and fall back to the current behavior otherwise?

I don't think switching the default generator to Ninja will actually solve the issue regarding support for newer Visual Studio versions.

While using Ninja avoids generating .sln files, it does not bypass the need to detect and configure the MSVC toolchain. Here is why switching to Ninja won't fix the underlying detection problem:

1. Dependency on Toolchain Probing: Even when using the Ninja generator, cmake-rs (and the underlying cc-rs crate) must still "probe" the system to locate the Visual Studio installation. It needs to find the correct paths for cl.exe, link.exe, and the Windows SDKs to set up the necessary environment variables (similar to what vcvarsall.bat does). If the probing logic fails because it doesn't recognize the new VS version/year, it will fail to set up the environment for Ninja just as it fails to generate a VS Solution.
2. Ninja is not Standard: Unlike MSBuild, Ninja is not available in the system PATH by default on Windows (even if installed via VS Build Tools). Making it the default would break the build for most Windows users unless they are strictly running inside a Developer Command Prompt or have manually added Ninja to their path.

Conclusion: The root cause is the outdated probing logic for the Visual Studio version, not the choice of generator. Simply switching to Ninja would likely just shift the error from "Generator not found" to "Compiler not found."

Therefore, we should stick to the existing logic and manually update the cmake-rs (and potentially cc-rs) codebase to explicitly support the new Visual Studio version identifiers.