## Description
Currently if you run CodeGen / react-native run-windows it will fail If you have a space in your user directory. I.e. in my case my directory was C:\Users\Alex Noble. The space in between Alex and Noble would trick CodeGen executable into thinking it was another parameter. Apologies if this is the wrong way to tackle this issue, new to the react-native-windows project and this is how I solved it on my machine.
### Type of Change
- Bug fix (non-breaking change which fixes an issue)
### Why
Motivation for this change was to allow users who have a space in their user directory to be able to build a c# project.
Resolves [Add Relevant Issue Here]
### What
Added quotes around the directories used in the CodeGen Exec
## Screenshots
## Changelog
Should this change be included in the release notes: yes
Fixed issue with managed codegen target failing when run from path with spaces
## Description
This PR adds a `RnwNewArch` MSBuild property and `RNW_NEW_ARCH` build-time constant / pre-processor directive for use by external (module) devs. This PR also updates `@react-native-windows/codegen` to use the directive when appropriate, and also applies those changes to `sample-custom-component`.
The expectation is that external devs now use these new properties and directives instead of the previously exposed `UseFabric`, `UseHermes` and/or `UseWinUI3` props. All logic expecting external developers to manually set those props has been removed and replaced with more robust checking that keys off `RnwNewArch` and throws warnings or errors if the other props aren't set correctly.
In addition, this PR adds further checks to make sure external projects load the WindowsSDK props sheet, followed by the appropriate RNW props and then the RNW targets. Failure to load these import properly would always risk putting the project in a broken state, now we at least tell people what they're missing.
Note: Old arch devs will still be able to toggle `UseHermes`.
### Type of Change
- Bug fix (non-breaking change which fixes an issue)
- New feature (non-breaking change which adds functionality)
- This change requires a documentation update
### Why
We don't want end-users to have access to conditionally build their code for the new or old architectures, without having to use/replicate the current complicated un-scoped directives we use internally.
Closes#13929
### What
See above.
## Screenshots
N/A
## Testing
Verified the flag exists and builds for the sample-custom-component. Also verified that new projects build properly.
## Changelog
Should this change be included in the release notes: _yes_
Add RnwNewArch property and RNW_NEW_ARCH constants when building projects for the new architecture
## Description
This PR upgrades the minimum version of `Microsoft.NETCore.UniversalWindowsPlatform` to 6.2.14 for UWP C# projects.
### Type of Change
- Bug fix (non-breaking change which fixes an issue)
### Why
This is long over-due as the latest (and probably last) version of this package hasn't changed in over two years. There's no reason for us to build against an older version. Just as importantly, this brings in a newer version of the .NetNative toolchain, which seems to resolve issues around C# builds hanging at the .NetNative step.
Resolves#14055Resolves#9194Resolves#4869
### What
Updated the minimum version of `Microsoft.NETCore.UniversalWindowsPlatform` to 6.2.14 for UWP C# projects. Added new entries to the props that enable C++ apps to consume C# modules to see the latest versions of .NetNative.
## Screenshots
N/A
## Testing
Verified E2Etests build and run.
## Changelog
Should this change be included in the release notes: _yes_
Update to Microsoft.NETCore.UniversalWindowsPlatform 6.2.14
## Description
This PR sets a timeout for the bundle command (`npx react-native bundle`) that happens during release builds with `run-windows`. This is because sometimes Metro can hang indefinitely even after it's done, causing the command to not exit, and otherwise hold up a good build from finishing.
The new timeout defaults to 5m (a new app takes ~40s to bundle) but this variable can easily be modified by defining `BundleCommandTimeoutMs` MSBuild property.
For our new project tests, setting the timeout to 1m, so that, in theory, if the bundle actually finished at 40s, then timing out won't block the remainder of the build.
### Type of Change
- Bug fix (non-breaking change which fixes an issue)
- New feature (non-breaking change which adds functionality)
### Why
See above.
May help fix some of the times we've seen hanging with #14055.
### What
See above.
## Screenshots
N/A
## Testing
Verified build continues after the timeout has hit.
## Changelog
Should this change be included in the release notes: _yes_
Add timeout to JS bundle creation in release builds
## Description
Fix CI to correctly enable/disable hermes.
### Type of Change
_Erase all that don't apply._
- Bug fix (non-breaking change which fixes an issue)
### Why
Accurate testing.
### What
Fixed the task that set the UseHermes experimental prop.
## Screenshots
N/A
## Testing
Verified UseHermes set to true now.
## Changelog
Should this change be included in the release notes: _no_
## Description
Updates our macOS testing in CI to the macos-latest VM image.
### Type of Change
- Bug fix (non-breaking change which fixes an issue)
### Why
To unblock CI.
### What
See above.
## Screenshots
N/A
## Testing
Verified tests pass.
## Changelog
Should this change be included in the release notes: _no_
* save state
* add example
* build but blank page still :(
* clean up comments
* visuals show up in new hwnd!
* clean up code
* better naming and unfork Modal examples
* testing save state
* Make the RN island a Modal member var
* Failed attempt at skipping root view in CEH, leaving it for learning purposes
* you can click on UI!
* clean up code
* Change files
* save state
* remove hardcoded rootTag
* add width/height to example
* add test
* revert simple.tsx
* remove test
* update snapshot
* feedback part 1: make Modal a RootComponentView
* feedback part2: simplify MountChildren
* fix deleting modal
* feedback round2
* remove comment
* remove imports
* feedback part 3
* fix overrides
* add simple layout - still has issues with padding/flex
* feedback part4
* lint
* update overrides
* Change files
* feedback
---------
Co-authored-by: Daniel Ayala <14967941+danielayala94@users.noreply.github.com>
## Description
Text components rendered in Paper need to have check if the style they are rendering contains border style props. This bug occurs when the passed in style is an array. From what I can tell, this bug has existed for a long time, possibly forever.
[4 Years Ago](946ba7fd7c) This PR fixed borders not rendering for text, but did not address text components with an array of styles.
[3 Years Ago](ee4d83d9a2 (diff-5beb08e50a61de475cd20c6e68588ac3a5cd687a971883167fe75fc97a0dbdea)) This PR changes naming, but not the logic.
This PR switches the style that is checked for border props from the one that is passed in to the one that is flattened.
This is the type of JSX that is broken. The text does not render a border.
```tsx
<Text style={[{ borderColor: "red", borderWidth: 3 }]}>{"hello world"}</Text>
```
### Type of Change
- Bug fix (non-breaking change which fixes an issue)
### Why
This reenables borders for Paper text components.
### What
Swapped a variable in text.window.js that is used to check for border style props.
## Screenshots
Add any relevant screen captures here from before or after your changes.
## Testing
Local tests.
## Changelog
Fixing text components not rendering a border with Paper
---------
Co-authored-by: Sam Walker <sawalker@microsoft.com>
Co-authored-by: Jon Thysell <thysell@gmail.com>
## Description
This PR updates the RNW CLI to preserve and re-use the arguments passed to `init-windows` when the project was created.
### Type of Change
- Bug fix (non-breaking change which fixes an issue)
- New feature (non-breaking change which adds functionality)
- This change requires a documentation update
### Why
The RNW CLI should be smart enough to change its command's behaviors based on the template used by the project.
Closes#13927Closes#13926Closes#13937Closes#13174
### What
As per #13927:
1. The `init-windows` command will now stamp the `template`, `name`, and `namespace` arguments to the project's `package.json` file as follows:
```json
{
"react-native-windows": {
"init-windows": {
"name": "testcli",
"namespace": "testcli",
"template": "cpp-app",
},
},
}
```
2. The `config` command (and therefore all other CLI commands) will now contain the contents of this new `react-native-windows` section in a new `rnwConfig` property.
Then, as per #13937:
1. The `init-windows` command will now use the previously saved arguments if they're available (and not otherwise overwritten by passed-in arguments)
2. If the template arg is missing (as it will be for all previously created projects) the `config` command will try to determine which template was used and inject it
Additionally, as per #13926:
1. The `autolink-windows` command will now use the template information to use the correct files when autolinking
Bonus, as per #13174:
1. The `autolink-windows` command will now include both the CPP and H file (the H file wasn't being regenerated before)
## Screenshots
N/A
## Testing
Verified new projects contain the new information.
## Changelog
Should this change be included in the release notes: _yes_
Update RNW CLI to preserve and re-use `init-windows` arguments
dependabot[bot]
React-Native-Windows Bot
Tatiana Kapos
Yajur Grover
Andrew Coates
Alex Noble
Jon Thysell
Daniel Ayala
Chiara Mooney
JesseCol
Sam Walker
Marlene Cota