BAZEL_VC does not work when vs2019 and vs2022 exist on windows 11.

[shelllet]

when i build tensorflow,
BAZEL awaly use Visual Studio 2022, even if i set BAZEL_VC BAZEL_VC_FULL_VERSION to vs 2019。

Auto-Configuration Error: Couldn't find undname.exe under C:\Program Files\Microsoft Visual Studio\2022\Community\VC, please check your VC installation and set BAZEL_VC environment variable correctly.
ERROR: Analysis of target '//tensorflow:tensorflow_cc.dll' failed; build aborted: Analysis failed
INFO: Elapsed time: 6.906s

[shelllet]

Visual Studio 2019 should be preferred over 2017
#10772

If i unistall visual studio 2022 RC and keep visual studio 2019 , everything is ok!

[shelllet]

maybe this is vcpkg's problem.

[shelllet]

i don't know this is a bug or not. or bazel can't support vs 2022 yet.

[gregestren]

I think you need to route this through tensorflow's project? Or whichever project defines BAZEL_VC BAZEL_VC_FULL_VERSION, which I don't believe is Bazel.

[meteorcloudy]

We do optionally support those env vars for detecting vc toolchains. See here.
@andrewkatson Can you help look into this one?

[OgreTransporter]

Bazel does not work with VS2022. No matter what I have tried, there is always the error that undname.exe cannot be found. I had to set BAZEL_VC global before building and run bazel as administrator.

BAZEL_VC=C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC

Thus, Bazel continues to use VS2019. I have installed VS2019 and VS2022 in parallel.

[andrewkatson]

@OgreTransporter how are you getting it to use 2022? I set BAZEL_VC and it just worked so I assume its using 2019 still.

Also my 2022 has no VC folder so it never gets chosen...

[OgreTransporter]

@andrewkatson VS2022 does not work! VS2022 has a VC folder somewhere at C:\Program Files\Microsoft Visual Studio\2022\<Edition>\VC. At least I have this folder. But, the initial problem was:

BAZEL awaly use Visual Studio 2022, even if i set BAZEL_VC BAZEL_VC_FULL_VERSION to vs 2019

If I set BAZEL_VC to VS2019 then Bazel also uses VS2019 for me, however I have not set the variable BAZEL_VC BAZEL_VC_FULL_VERSION. I have no problems with parallel installation of 2019 and 2022.

Bazel is a disaster for Windows users. It doesn't work very reliably. Maybe only on Mondays or every first Saturday of the month - no idea, who knows? Now and then it works with VS2019, but VS2022 is not supported at all. And even if VS2022 should work in a future version, it doesn't help anyone who wants to compile TensorFlow, because the mandatory Bazel version for TF is always significantly behind the development. I would like to see a change in the build system for TF, so that you can also work with TF on Windows. It is no use if everything is compiled for Linux, but the majority of users work with Windows.

I have also tried with LLVM/CLANG, which uses Visual Studio internally, but Bazel is simply ignoring the CLANG command and whines that no Visual Studio can be found.

[Zhaopudark]

I have built tensorflow2.8.0rc0 with bazel 4.2.2 successfully, where I
only used Visual Studio 2022 but with old msvc v142 tools set installed.

My solution is:

1. Firstly, make a soft link named "C:\Program Files\Microsoft Visual Studio\2019" to “C:\Program Files\Microsoft Visual Studio\2022”
2. Then set 2 env variable like
   $env:BAZEL_VC="C:\Program Files\Microsoft Visual Studio\2019\Community\VC"
   $env:BAZEL_VC_FULL_VERSION="14.29.30133"

[meteorcloudy]

@andrewkatson and I did some debugging on this. VC 2022 doesn't work with 4.2.2 but it works fine with 5.0.0rc3 and can be overridden to older VC with BAZEL_VC env var.

This is the same cause of #11259, which is already fixed at HEAD at d155376.
The fix is included in Bazel 5.0, which will be released soon, we'll also help TensorFlow migrate to 5.0 after that.
And we can certainly consider cherry-picking the fix for Bazel 4.x if there is a new minor/patch release.

[ludiccc]

$env:BAZEL_VC="C:\Program Files\Microsoft Visual Studio\2019\Community\VC"

Is important to notice that the BAZEL_VC MUST have the double quotes. Otherwise, it breaks.