-
Notifications
You must be signed in to change notification settings - Fork 473
fix(windows) Change WindowsTargetPlatformVersion to 10.0 #810
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
tido64
approved these changes
Jun 1, 2022
Thanks for fixing this ❤️ |
🎉 This PR is included in version 1.17.6 🎉 The release is available on: Your semantic-release bot 📦🚀 |
chrisglein
added a commit
to chrisglein/clipboard
that referenced
this pull request
Mar 24, 2023
chrisglein
added a commit
to chrisglein/clipboard
that referenced
this pull request
Mar 24, 2023
chrisglein
added a commit
to chrisglein/clipboard
that referenced
this pull request
Mar 24, 2023
chrisglein
added a commit
to chrisglein/picker
that referenced
this pull request
Mar 24, 2023
This was referenced Mar 24, 2023
5 tasks
chrisglein
added a commit
to chrisglein/clipboard
that referenced
this pull request
Sep 14, 2023
See react-native-async-storage/async-storage#810 SDK import defers to app preference Keep SDK version neutral
chrisglein
added a commit
to chrisglein/picker
that referenced
this pull request
Sep 14, 2023
See react-native-async-storage/async-storage#810 Update SDK logic based on PR feedback
1 task
Naturalclar
pushed a commit
to react-native-picker/picker
that referenced
this pull request
Sep 20, 2023
* Remove explicit SDK version See react-native-async-storage/async-storage#810 Update SDK logic based on PR feedback * Update Cpp.Default.props order per feedback
tboba
pushed a commit
to software-mansion/react-native-screens
that referenced
this pull request
Sep 20, 2023
## Description When using a `StackNavigator` on an app on Windows, when you popped the stack you would end up with no displayed content instead of the first page. ## Changes The Windows stack implementation wasn't updating `Content` to the top of the stack (after the removal and motification of the vector). Also the Windows project had an aggressive assertion of SDK version, causing apps to unnecessarily either download an older SDK or patch their app. See react-native-async-storage/async-storage#810 for a similar fix. ## Test code and steps to reproduce ```jsx import { NavigationContainer } from '@react-navigation/native'; import { createNativeStackNavigator } from '@react-navigation/native-stack'; // ,,, const Stack = createNativeStackNavigator(); export default function App() : JSX.Element { return ( <NavigationContainer> <Stack.Navigator initialRouteName='Home'> <Stack.Screen name='Home' component={HomeScreen} /> <Stack.Screen name='Details' component={DetailsScreen} /> </Stack.Navigator> </NavigationContainer> ); } ``` Somewhere else ```jsx navigation.navigate('Details'); ``` And then later ```jsx navigation.goBack(); ``` Result: rendering nothing instead of the 'Home' page. Yep, that's all it took. As far as I can tell this was broken since implementation, but the usage I know of on Windows was using Drawer and that part's all fine. ## Checklist - [x] Included code example that can be used to test this change - [x] Updated TS types **N/A** - [x] Updated documentation: **N/A** - [x] Ensured that CI passes **No tests on Windows :'(** - [x] _Tested via patch-packing in an app_
mccoyplayer
pushed a commit
to mccoyplayer/reactScreen
that referenced
this pull request
Feb 9, 2024
## Description When using a `StackNavigator` on an app on Windows, when you popped the stack you would end up with no displayed content instead of the first page. ## Changes The Windows stack implementation wasn't updating `Content` to the top of the stack (after the removal and motification of the vector). Also the Windows project had an aggressive assertion of SDK version, causing apps to unnecessarily either download an older SDK or patch their app. See react-native-async-storage/async-storage#810 for a similar fix. ## Test code and steps to reproduce ```jsx import { NavigationContainer } from '@react-navigation/native'; import { createNativeStackNavigator } from '@react-navigation/native-stack'; // ,,, const Stack = createNativeStackNavigator(); export default function App() : JSX.Element { return ( <NavigationContainer> <Stack.Navigator initialRouteName='Home'> <Stack.Screen name='Home' component={HomeScreen} /> <Stack.Screen name='Details' component={DetailsScreen} /> </Stack.Navigator> </NavigationContainer> ); } ``` Somewhere else ```jsx navigation.navigate('Details'); ``` And then later ```jsx navigation.goBack(); ``` Result: rendering nothing instead of the 'Home' page. Yep, that's all it took. As far as I can tell this was broken since implementation, but the usage I know of on Windows was using Drawer and that part's all fine. ## Checklist - [x] Included code example that can be used to test this change - [x] Updated TS types **N/A** - [x] Updated documentation: **N/A** - [x] Ensured that CI passes **No tests on Windows :'(** - [x] _Tested via patch-packing in an app_
ja1ns
pushed a commit
to WiseOwlTech/react-native-screens
that referenced
this pull request
Oct 9, 2024
## Description When using a `StackNavigator` on an app on Windows, when you popped the stack you would end up with no displayed content instead of the first page. ## Changes The Windows stack implementation wasn't updating `Content` to the top of the stack (after the removal and motification of the vector). Also the Windows project had an aggressive assertion of SDK version, causing apps to unnecessarily either download an older SDK or patch their app. See react-native-async-storage/async-storage#810 for a similar fix. ## Test code and steps to reproduce ```jsx import { NavigationContainer } from '@react-navigation/native'; import { createNativeStackNavigator } from '@react-navigation/native-stack'; // ,,, const Stack = createNativeStackNavigator(); export default function App() : JSX.Element { return ( <NavigationContainer> <Stack.Navigator initialRouteName='Home'> <Stack.Screen name='Home' component={HomeScreen} /> <Stack.Screen name='Details' component={DetailsScreen} /> </Stack.Navigator> </NavigationContainer> ); } ``` Somewhere else ```jsx navigation.navigate('Details'); ``` And then later ```jsx navigation.goBack(); ``` Result: rendering nothing instead of the 'Home' page. Yep, that's all it took. As far as I can tell this was broken since implementation, but the usage I know of on Windows was using Drawer and that part's all fine. ## Checklist - [x] Included code example that can be used to test this change - [x] Updated TS types **N/A** - [x] Updated documentation: **N/A** - [x] Ensured that CI passes **No tests on Windows :'(** - [x] _Tested via patch-packing in an app_
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Changed to general version for WindowsTargetPlatformVersion
Using an explicit version of WindowsTargetPlatformVersion requires that specific windows SDK version to be installed on the machine.
In Visual Studio 2017 (version 15 or build tools 141) and earlier it was required but as of Visual Studio 2019 (v16 or v142) and Visual Studio 2022(v17 or v143) you can simply specify "10.0". This allows a lot more flexibility to the developer or build machine as there is a growing number of different windows 10 SDK out there now.
Test Plan
You can now install/run on machines without needing as specific of a windows 10.0 version (think of this as saying using the latest version of windows 10 sdk you have installed, so long as it meets the WindowsTargetPlatformMinVersion.
Newer versions of azure hosted windows images have a different subset.
VS2022 Azure Window image has
10.0.17763.0, 10.0.19041.0, 10.0.20348.0, 10.0.22000.0
VS2019 Azure Window image had
10.0.14393.0, 10.0.16299.0, 10.0.17134.0, 10.0.17763.0, 10.0.18362.0, 10.0.19041.0, 10.0.20348.0, 10.0.22000.0