Unable to deploy RNW app after upgrade to VS 17.10.2 #13339
Labels
Blocking
High severity blocker issue
bug
Developer First Experience
Issues that are going to be hit by a new developer as they first try out RNW
External Developer Tooling
Issue caused by the tool chain, not by RNW itself
Scenario: Visual Studio
Milestone
Comments
jonthysell
added
bug
Developer First Experience
microsoft-github-policy-service
bot
added
the
Needs: Triage 🔍
|
This appears to be a recurring phenomenon with VS upgrades, see #10155. |
jonthysell
changed the title
|
As this looks similar to what cropped up 2 years ago: #10155 (comment) @srdjanjovcic could you please take a look? It looks like DeployAppRecipe is failing again. |
chrisglein
removed
the
Needs: Triage 🔍
jonthysell
added a commit
that referenced
this issue
Jun 13, 2024
Reverting our CI/PR agent images to an older version of VS 2022, specficially 17.9.7, due build failures introduced by the (automatic) upgrade to 17.10.2. See issue #13339 as an example. Note this PR does not cause our images to change, this is just a backup of the agent image config which we keep and version here to track what is being used in Azure.
|
Do you have any idea on this one? I'm on 17.10.2, should I install a different version? |
|
VS Profesional fixed version 17.9.7 is working for me, you can find it here https://learn.microsoft.com/en-us/visualstudio/releases/2022/release-history |
|
The problem appears to be a bug in the |
|
We're currently working on a solution with the Visual Studio team, the best current workaround is at the top of the bug description. |
jonthysell
added a commit
that referenced
this issue
Jun 20, 2024
Reverting our CI/PR agent images to an older version of VS 2022, specifically 17.9.7, due build failures introduced by the (automatic) upgrade to 17.10.2. See issue #13339 as an example. Note this PR does not cause our images to change, this is just a backup of the agent image config which we keep and version here to track what is being used in Azure.
|
The bug appears to be fixed in the next VS 2022 Preview release, version 17.11.0, but that's not out yet and it has its own issues: #13374 |
jonthysell
added a commit
that referenced
this issue
Jun 21, 2024
…` to use a particular version of VS installed (#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 #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
added a commit
to jonthysell/react-native-windows
that referenced
this issue
Jun 24, 2024
…windows` to use a particular version of VS installed This PR backports microsoft#13373 to 0.74. ## 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
added a commit
that referenced
this issue
Jun 26, 2024
…windows` to use a particular version of VS installed (#13380) This PR backports #13373 to 0.74. ## 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 #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
|
This fix for this will be in VS 17.10.4. |
|
Is there any ETA on when 17.10.4 will be out? The cadence is somewhat irregular according to this. |
Does this workaround work fine for you guys when building a release? This seems to work fine when in debug mode, but when I'm trying to make an actual release, I'm getting this issue at the end (@jonthysell): |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This bug will be fixed in VS 17.10.4. Please upgrade to VS 17.10.4 when it's available. In the meantime, you can use the workaround below:
Problem Description
Trying to build/launch/deploy a RNW app with
run-windowsgives the following error:Steps To Reproduce
npx react-native run-windows --loggingin an RNW appExpected Results
App deploys and launches
CLI version
14.0.0-alpha.2
Environment
info Fetching system and libraries information... System: OS: Windows 11 10.0.22631 CPU: "(24) x64 AMD Ryzen Threadripper PRO 3945WX 12-Cores " Memory: 53.52 GB / 63.86 GB Binaries: Node: version: 18.18.0 path: C:\Program Files\nodejs\node.EXE Yarn: version: 1.22.22 path: C:\Program Files (x86)\Yarn\bin\yarn.CMD npm: version: 9.8.1 path: C:\Program Files\nodejs\npm.CMD Watchman: Not Found SDKs: Android SDK: Not Found Windows SDK: AllowDevelopmentWithoutDevLicense: Enabled AllowAllTrustedApps: Enabled Versions: - 10.0.19041.0 - 10.0.22621.0 IDEs: Android Studio: Not Found Visual Studio: - 17.10.35004.147 (Visual Studio Enterprise 2022) Languages: Java: Not Found Ruby: Not Found npmPackages: "@react-native-community/cli": Not Found react: Not Found react-native: Not Found react-native-windows: Not Found npmGlobalPackages: "*react-native*": Not Found Android: hermesEnabled: Not found newArchEnabled: Not found iOS: hermesEnabled: Not found newArchEnabled: Not foundCommunity Modules
No response
Target Platform Version
10.0.22621
Target Device(s)
Desktop
Visual Studio Version
Visual Studio 2022
Build Configuration
Debug
Snack, code example, screenshot, or link to a repository
No response
The text was updated successfully, but these errors were encountered: