You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It'd be great if either vswhere could implement a forward-compatible non-hack to determine the platform toolset version(s) available, or if that's not possible, at least centralize the hacks so build tools can avoid each have their own implementations.
There is an implied solution in vcvars.bat, where it will read the value of VCToolsVersion from %VCINSTALLDIR%Auxiliary\Build\Microsoft.VCToolsVersion.v143.default.txt if it exists, and fall back to the value in %VCINSTALLDIR%Auxiliary\Build\Microsoft.VCToolsVersion.default.txt ("latest" according to the comments).
So I believe the correct solution would be to search %VCINSTALLDIR%Auxiliary\Build\Microsoft.VCToolsVersion.*.default.txt, extract the platform toolset version from the filename, and read the VCToolsVersion from the file. Including the "latest" tools version from Microsoft.VCToolsVersion.default.txt would be nice too.
This doesn't work however when there are multiple SxS versions of the same platform toolset, as they will be in Auxilliary\Build\XX.YY.MM.mm\Microsoft.VCToolsVersion.XX.YY.MM.mm.txt with no way to map XX.YY to a platform toolset version since the XX.YY suffers from the same v144 issue we're trying to solve.
The text was updated successfully, but these errors were encountered:
@mjcavallari-zz this seems to fall well outside the purview of vswhere, but could the VC team provide some sort of script to enumerate all the permutations? Perhaps vswhere can find the script and VC would control what developers need to know. They should at least be mindful of the changes they make and how developers are supposed to discover them. Not everyone uses the VS dev prompts for various reasons.
With the introduction of VS 17.1x earlier this year, and the subsequent bump of
VCToolsVersion
to14.4x.xxxxx
, it's now necessary for build tools to include a non-forward compatible hack to check for the platform toolsetv143
since it's otherwise identified asv144
(see https://devblogs.microsoft.com/cppblog/msvc-toolset-minor-version-number-14-40-in-vs-2022-v17-10/).e.g.:
It'd be great if either vswhere could implement a forward-compatible non-hack to determine the platform toolset version(s) available, or if that's not possible, at least centralize the hacks so build tools can avoid each have their own implementations.
There is an implied solution in
vcvars.bat
, where it will read the value ofVCToolsVersion
from%VCINSTALLDIR%Auxiliary\Build\Microsoft.VCToolsVersion.v143.default.txt
if it exists, and fall back to the value in%VCINSTALLDIR%Auxiliary\Build\Microsoft.VCToolsVersion.default.txt
("latest" according to the comments).So I believe the correct solution would be to search
%VCINSTALLDIR%Auxiliary\Build\Microsoft.VCToolsVersion.*.default.txt
, extract the platform toolset version from the filename, and read theVCToolsVersion
from the file. Including the "latest" tools version fromMicrosoft.VCToolsVersion.default.txt
would be nice too.This doesn't work however when there are multiple SxS versions of the same platform toolset, as they will be in
Auxilliary\Build\XX.YY.MM.mm\Microsoft.VCToolsVersion.XX.YY.MM.mm.txt
with no way to mapXX.YY
to a platform toolset version since theXX.YY
suffers from the samev144
issue we're trying to solve.The text was updated successfully, but these errors were encountered: