Skip to content

Conversation

@jonthysell
Copy link
Contributor

@jonthysell jonthysell commented Aug 16, 2024

This PR backports #13455 to 0.72.

Description

This PR bumps the minimum version of VS that RNW expects to 17.11.0.

Type of Change

  • Bug fix (non-breaking change which fixes an issue)

Why

To make sure users don't use the regressed builds of VS 2022.

Resolves #13339
Resolves #13374

What

Bumped VS version checks for run-windows and rnw-dependencies.ps1. Updated ADO image to reflect updated images are no longer locked to VS v17.9.4.

Screenshots

N/A

Testing

run-windows now works with 17.11.0.

Changelog

Should this change be included in the release notes: yes

Require Visual Studio 2022 >= v17.11.0

Microsoft Reviewers: Open in CodeFlow

This PR backports microsoft#13455 to 0.72.

## Description

This PR bumps the minimum version of VS that RNW expects to 17.11.0.

### Type of Change
- Bug fix (non-breaking change which fixes an issue)

### Why
To make sure users don't use the regressed builds of VS 2022.

Resolves microsoft#13339
Resolves microsoft#13374

### What
Bumped VS version checks for `run-windows` and `rnw-dependencies.ps1`. Updated ADO image to reflect updated images are no longer locked to VS v17.9.4.

## Screenshots
N/A

## Testing
`run-windows` now works with 17.11.0.

## Changelog
Should this change be included in the release notes: _yes_

Require Visual Studio 2022 >= v17.11.0
@jonthysell jonthysell requested review from a team as code owners August 16, 2024 18:28
@jonthysell jonthysell enabled auto-merge (squash) August 16, 2024 18:29
…` to use a particular version of VS installed (microsoft#13373)

## Description

Fixes a bug in `run-windows` where we truncate the minimum VS version number so it only allows for one digit minor versions.

We try to detect when building inside a VS command prompt by looking for the `VisualStudioVersion` environment variable. In this way we can make sure to use specific (usually prerelease/preview) versions of VS.

However, we can also set this env variable manually, which I was trying to do. However, there are lots of other places in VS that read this value, and it always expects a major version with a 0 minor version (i.e. `17.0`, `18.0`). When setting `17.11`, (the version I'm trying to test for has fixes to microsoft#13339) the code was truncating it to `17.1`. Even fixing the truncation meant that the build would later fail anyway, since it wasn't a  `X.0` number.

So this PR not only fixes the truncating code to keep `17.11` as `17.11`, but also adds a *new* env variable to check for, i.e. `MinimumVisualStudioVersion`, so that we can safely override that without breaking the build.

### Type of Change
- Bug fix (non-breaking change which fixes an issue)

### Why
Trying to test with VS 17.11 preview, the number kept getting truncated to 17.1. I need a way of specify the version I want without breaking the build

### What
Fixes the version range calculating code to not truncate the digits, adds new `MinimumVisualStudioVersion` env variable.

## Screenshots
N/A

## Testing
Verified run-windows could fine the preview 17.11 over the regular 17.10 installed.

## Changelog
Should this change be included in the release notes: yes

Added `MinimumVisualStudioVersion` env variable to force `run-windows` to use a particular version of VS installed
@jonthysell jonthysell merged commit becc1d3 into microsoft:0.72-stable Aug 20, 2024
@jonthysell jonthysell deleted the vs11_72 branch August 20, 2024 19:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants