On Mon, 28 Sep 2026 08:44:31 GMT, Christopher Schnick <[email protected]> wrote:
> I frequently ran into this issue when setting up a new system where you would > have manually set env variables if the install location of Visual Studio was > different or it was using VS2026 (which is not officially supported, but > works for development). > > This approach is simpler, detects more installations, automatically filters > out incompatible ones, and is future proof in terms of new versions. > > For testing, removing any VS env vars and deleting the > build/windows_tools.properties file, should make this logic trigger > > --------- > - [x] I confirm that I make this contribution in accordance with the [OpenJDK > Interim AI Policy](https://openjdk.org/legal/ai). Alright, I can readd the old logic as well. However, by definition of a valid Visual Studio install, the vswhere executable is always there. So in theory, that old logic will never be reached as a fallback I can image vswhere not working properly some years ago when VS2015 was still considered acceptable in the selection. Other than that, I never encountered any issues with vswhere in other projects so far. Furthermore in terms of old logic, is VS 2017 even still supported? ------------- PR Comment: https://git.openjdk.org/jfx/pull/2330#issuecomment-5872313241 PR Comment: https://git.openjdk.org/jfx/pull/2330#issuecomment-5872360113
