Skip to content
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

BabylonNative UWP dependencies should be converted to a single dll to decrease package file size #146

Open
chrisfromwork opened this issue Jan 28, 2021 · 3 comments
Milestone

Comments

@chrisfromwork
Copy link
Contributor

chrisfromwork commented Jan 28, 2021

Right now published packages supporting windows have greatly increased the package file size (60mb -> 960mb). There are some issues with react-native-windows and multi-layer referencing that make this difficult to fix. But we should do something to get back to a smaller package size.

talking to other folks it also sounds like it is already bad practice to distribute static libs. If folks try and build BabylonReactNative.dll with a compiler/linker version that doesn't match the static libs, we will get into unsupported/undefined behavior.

@chrisfromwork chrisfromwork changed the title BabylonNative UWP dependencies should be converted to a single dll to decrease file size BabylonNative UWP dependencies should be converted to a single dll to decrease package file size Jan 28, 2021
@chrisfromwork
Copy link
Contributor Author

chrisfromwork commented Jan 28, 2021

in order to support multiple react-native-windows projects referencing Microsoft.ReactNative.vcxproj, it seems like we actually need Microsoft.ReactNative.dll/winmd distributed as a precompiled binary that all consuming projects reference. Otherwise different versions of Microsoft.ReactNative.dll will be built for the npm package vs applications consuming the npm package and we will always have conflicting xbf files/compilation timestamps/hashes

@chrisfromwork
Copy link
Contributor Author

it seems like specifically we may need the following change: microsoft/react-native-windows#4540

@chrisfromwork
Copy link
Contributor Author

chrisfromwork commented Feb 4, 2021

Initial context

  • For 0.64.0, react-native-windows dependencies are distributed as source in npm packages
    • This prevents being able to precompile a DLL that references ABI safe react-native-windows types defined in Microsoft.ReactNative.dll
  • You will encounter conflicting winmds/compilation timestamps/duplicate xaml xbf files when attempting to use binaries built against different versions of the same winrt/cpp dll in the same application.
    • These errors primarily reveal themselves during appx packaging compared to individual component compilation
    • When all native modules are compiled at the same time to build the application, the same react-native-windows dlls are used and everything works fine.
  • BabylonReactNative relies on a lot of source code that isn't practical to distribute in a npm package
  • We currently distribute BabylonNative static libs, which can result in unknown linker behaviors when using different compiler versions, so this isn't a great long term solution
  • BabylonNative static libs also greatly increase the @babylonjs/react-native npm package size (we went from ~60mb to ~1gb package size when introducing these dependencies)

Goal:

  • We want to distribute BabylonNative static lib dependencies in a single BabylonNative.dll
    • This will prevent compiler version issues that can occur today due to relying on distributing static libs
    • This will decrease the overall npm package size

How we can do this:

  • React-native-windows is setting up a NuGet feed for consuming Microsoft.ReactNative.dll and Microsoft.ReactNative.Cxx content
  • The rough expectation is that 0.65+ react-native-windows releases will rely on referencing binaries distributed by the NuGet feed
  • A react-native-windows NuGet feed means that all native module projects can be built against the same precompiled Microsoft.ReactNative.dll. This will allow us to precompile BabylonReactNative.dll/BabylonNative.dll against the same Microsoft.ReactNative.dll that is used by the react-native-windows application or community modules

NuGet feed usage

  • For a new project, running npx react-native-windows-init --experimentalNuGetDependency true should setup new windows react-native projects to consume content from the NuGet feed
    • This roughly does the following:
      • A 'UseExperimentalNuget' property is set in the application/native module component's ReactNativeWindowsProps PropertyGroup to change project references to look for the NuGet feed binaries
      • packages.config for your application/native module is updated to contain some form of the nuget feed references
      • A NuGet.Config file will be added that references the public azure dev ops nuget feed: https://github.com/microsoft/react-native-windows/blob/master/vnext/NuGet.Config

Other knowns/Issues:

  • Precompiled binaries in the existing azure dev ops react-native-windows NuGet feed are not currently signed
  • The react-native-windows NuGet feed should move to nuget.org over time
  • Today, react-native-windows applications can only contain native modules that are built with the NuGet feed OR are all built from source when building the application. It is not currently supported to use both forms of community module
    • BabylonReactNative currently has dependencies on @react-native-community/slider and react-native-permissions, both of which aren't built against the NuGet feed
  • React-native-windows autolinking can't currently resolve dlls/winmds added to an npm package. This means that for BabylonReactNative, we may have a BabylonReactNative component distributed as source that works with autolinking that references a precomiled BabylonNative.dll
  • NuGet distributed dlls/winmds seem to currently have CopyFiles = true set. This causes duplicate winmd files to be found for Microsoft.ReactNative.dll and breaks builds. This error seems similar to the following: MDM2009 duplicate type error when using a grandchild reference microsoft/cppwinrt#452

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

No branches or pull requests

2 participants