Fix Windows embedded source build

[CedricGuillemet]

Summary

• package Babylon Native's embedded source tree and build it from Android, iOS, and Windows consumer projects
• make the Windows MSBuild bridge run CMake only after React Native Windows generates its C++/WinRT projections
• pass RNW's generated projection tree to every CMake target, inherit RNW's Microsoft.Windows.CppWinRT package policy, and remove the duplicate legacy packages.config integration
• compile the embedded Windows graph as C++20 and isolate CMake outputs by configuration, toolset, generator, and platform while keeping paths below legacy MSBuild limits
• add blocking Windows source-tree and packaged-tarball consumer builds
• keep the Playground controls visible and interactive above native rendering surfaces on Android and Windows, report XR startup errors, and contribute optional ARCore manifest metadata

Windows C++/WinRT compatibility

The generated React Native Windows projection tree is the single source of C++/WinRT headers for the embedded CMake build. The build fails if that tree is unavailable instead of silently falling back to a potentially different Windows SDK projection version. This keeps BRN aligned with the RNW version selected by the consuming application rather than pinning BRN to one machine-specific SDK projection.

Windows consumer CI keeps C++20 scoped to BRN's embedded CMake graph and the generated test application; it does not change RNW source projects. Autolinked native modules are restored and compiled independently against the consumer-selected RNW NuGet packages, then the generated x64 application is compiled through C++/WinRT and XAML and linked as ReactTestApp.exe. AppX packaging is intentionally excluded because it requires resource artifacts from recursively built RNW source projects, which are outside the NuGet consumer graph being validated.

Validation

• all jobs passed in PR Build run 34877434422, including the Windows source-tree consumer and packaged-tarball consumer
• both Windows jobs compile the embedded Babylon Native sources, autolinked native modules, generated C++/WinRT/XAML application code, and link the x64 application
• built and installed the Windows Playground package locally and visually confirmed all controls render correctly
• built the full Android Debug app with libReactNativeBabylon.so, installed it on a physical Pixel 9a, and confirmed the native rendering surface no longer overlaps the controls
• confirmed Android XR startup reaches the camera permission flow without the previous missing com.google.ar.core manifest failure
• Playground regression suite passes: controls are layered above EngineView, and rejected XR startup and shutdown are surfaced to the user
• merged the latest origin/master into the PR branch

[Copilot]

🟡 Changes recommended

Critical RNW compatibility and moderate Windows consumer-validation issues remain unresolved.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Fixes Windows embedded-source builds by aligning CMake/MSBuild with RNW-generated C++/WinRT projections, adding CI validation, and improving Playground XR/UI behavior.

Changes:

• Reworks Windows CMake/MSBuild integration, C++20 settings, output isolation, and legacy package cleanup.
• Adds Windows source and packaged-consumer CI coverage.
• Updates Playground controls, XR error handling, tests, and optional Android ARCore metadata.

File summaries

File	Summary / final finding
Package/gulpfile.js	Excludes generated Windows build artifacts from packages.
Modules/@babylonjs/react-native/windows/CMakeLists.txt	Requires RNW projections and enables C++20.
Modules/@babylonjs/react-native/windows/BabylonReactNative/PropertySheet.props	Isolates generated files by configuration.
Modules/@babylonjs/react-native/windows/BabylonReactNative/packages.config	Removes legacy package integration. Nit (1 vote): .vcxproj.filters retains a stale packages.config entry.
Modules/@babylonjs/react-native/windows/BabylonReactNative/BabylonReactNative.vcxproj	Updates RNW and CMake integration. Critical (2 votes): the new CppLib imports remove compatibility with documented older RNW layouts.
Modules/@babylonjs/react-native/shared/BabylonNative.cpp	Removes obsolete frame-update handling.
Modules/@babylonjs/react-native/android/src/main/AndroidManifest.xml	Adds optional ARCore metadata.
Apps/Playground/package-windows.json	Updates the React Native Windows dependency.
Apps/Playground/package-lock-windows.json	Refreshes locked Windows dependencies.
Apps/Playground/jest.config.js	Adds Jest configuration.
Apps/Playground/generate-windows-test-app.mjs	Generates the Windows test solution.
Apps/Playground/App.tsx	Layers controls above rendering and reports XR errors. Nit (3 votes): stop failures can be reported as start failures.
Apps/Playground/__tests__/App.test.tsx	Adds control-layering and XR failure tests.
.github/workflows/windows.yml	Adds blocking Windows source-build CI. Moderate (2 votes): builds only the library project, not the generated Playground solution.
.github/workflows/test_windows.yml	Adds packaged Windows validation. Moderate (2 votes): does not build the packaged Playground solution. Moderate (1 vote): ignores the copied lockfile and resolves dependencies afresh.
.github/workflows/pr.yml	Enables Windows build and package jobs.

Review details

Suppressed comments (2)

.github/workflows/test_windows.yml:45

• The copied package-lock-windows.json is ignored by --package-lock=false, so this packaged-consumer build resolves the package ranges afresh instead of testing the checked-in dependency graph. That makes the CI result non-reproducible and means lockfile changes are not actually validated.

          npm install --no-save --package-lock=false $package.FullName

Modules/@babylonjs/react-native/windows/BabylonReactNative/packages.config:1

• Removing packages.config leaves BabylonReactNative.vcxproj.filters with a stale <None Include="packages.config" /> entry. The packaged project will still advertise a file that is not shipped; remove that filter entry as part of this legacy NuGet integration cleanup.

• Files reviewed: 16/16 changed files
• Comments generated: 4
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[RaananW]

🤖 This review comment was created by an AI agent.

Thanks for adding direct Windows consumer checks. Both Windows jobs fail on the current head. The solution-wide LanguageStandard=stdcpp20 setting at .github/workflows/windows.yml:48-52 and .github/workflows/test_windows.yml:63-67 also changes Microsoft.ReactNative.vcxproj. RNW then mixes std::coroutine_handle and std::experimental::coroutine_handle, so both consumer builds fail. Please keep C++20 scoped to the projects that need it and restore green Windows checks.

Automated monitor correction: this repository is excluded from auto-review because its name contains Native.

[RaananW]

🤖 This review comment was created by an AI agent.

Thank you for adding direct Windows consumer checks. The current head is unchanged since the earlier review, and both Windows jobs still fail. The solution-wide LanguageStandard=stdcpp20 setting also changes Microsoft.ReactNative.vcxproj, which mixes standard and experimental coroutine types. Please keep C++20 scoped to the projects that need it and restore green Windows checks.

This review was submitted by the automated monitor in error. BabylonReactNative is excluded from automatic reviews by the repository-name rule.