search

microsoft / vswhere

Locate Visual Studio 2017 and newer installations
MIT License
923 stars 98 forks source link

`-version` filter doesn't appear to work correctly when Dev17 installed #238

Closed RussKie closed 3 years ago

RussKie commented 3 years ago

As reported in https://github.com/dotnet/arcade/issues/7324.

Since I've installed Dev17 I am having troubles building C++ projects, that depend on VSWhere for location of VC 16.* toolsets.

dotnet/arcade Microsoft.DotNet.CMake.Sdk is looking for the latest installed Dev16, however the filter doesn't appear to be applied correctly:

C:\Development\winforms>C:\Users\igveliko\.nuget\packages\vswhere\2.8.4\tools\vswhere.exe -latest -prerelease -products * -version [,17.0) -requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64 -property installationVersion
17.0.31418.319               <-- expected 16.11.31418.215

I also tried other variants, but none yields the expected retult:

C:\Development\winforms>C:\Users\igveliko\.nuget\packages\vswhere\2.8.4\tools\vswhere.exe -prerelease -products * -version [,17.0) -requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64 -property installationVersion
16.11.31418.215
17.0.31418.319
16.10.31410.357

C:\Development\winforms>C:\Users\igveliko\.nuget\packages\vswhere\2.8.4\tools\vswhere.exe -latest -products * -version [,17.0) -requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64 -property installationVersion
16.10.31410.357

C:\Development\winforms>C:\Users\igveliko\.nuget\packages\vswhere\2.8.4\tools\vswhere.exe -products * -version [,17.0) -requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64 -property installationVersion
16.10.31410.357
heaths commented 3 years ago

Did you try passing -all? The product state may not be complete e.g. a reboot is required, which means the product is in an unsupported state (and why vswhere doesn't find it by default) until the machine is rebooted.

heaths commented 3 years ago

Also try without the component passed to -requires. It's possible the component name changed, though it shouldn't have.

RussKie commented 3 years ago

Did you try passing -all?

C:\Development\winforms>C:\Users\igveliko\.nuget\packages\vswhere\2.8.4\tools\vswhere.exe -latest -prerelease -products * -version [,17.0) -requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64 -property installationVersion -all
17.0.31418.319

Also try without the component passed to -requires.

C:\Development\winforms>C:\Users\igveliko\.nuget\packages\vswhere\2.8.4\tools\vswhere.exe -latest -prerelease -products * -version [,17.0)  -property installationVersion
17.0.31418.319

. . .

The bug is in the resolution of the lower boundary, because once the lower boundary is specified this yields the expected result:

C:\Development\winforms>C:\Users\igveliko\.nuget\packages\vswhere\2.8.4\tools\vswhere.exe -latest -prerelease -products * -version [,17.0) -requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64 -property installationVersion
17.0.31418.319

C:\Development\winforms>C:\Users\igveliko\.nuget\packages\vswhere\2.8.4\tools\vswhere.exe -latest -prerelease -products * -version [15,17.0) -requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64 -property installationVersion
16.11.31418.215
heaths commented 3 years ago

Good find! That was supposed to be a supported case and I thought I had unit tests for that and similar cases. I'm hesitant to fix it, though. I worry that, despite being a bug, changing this behavior could introduce unexpected build breaks in pipelines which use vswhere, which are numerous.

We'll discuss internally. Thanks for finding this, and I'm glad you found a workaround. We will at least document that a lower bound is recommended.

heaths commented 3 years ago

Thank you for the report. After discussing internally, we decided the risk of regressions to build systems that use vswhere is too great.