Enable the CLI to create a C# native module library that consumes Microsoft.ReactNative

[jonthysell]

Project should be set up similar to the SampleLibraryCS sample:

• C# component library
• Depends only on Microsoft.ReactNative and Microsoft.ReactNative.Managed
• Provides a ReactPackageProvider that automatically includes all native modules, and view managers
• Provides a simple sample native module

[jonthysell]

Stretch goal for M3, possibly move to M4.

[jonthysell]

Potentially considering putting this in @brodybits/create-react-native-module, rather than our own CLI.

[brodybits]

Possibly off-topic: I personally find it somewhat problematic to deal with what seem to be separate and incompatible .NET (C#) and C++ react-native-windows versions. My understanding is that .NET should eventually be considered deprecated. But if you guys have too many users relying on the .NET implementation, this could be extremely "easier said than done".

I am now wondering if there may be any way for react-native-windows to support both .NET and C++ components, with .NET support deprecated, for a hopefully limited period of time. Even if not so efficient in performance, I think it would help give users a more linear transition path.

Any thoughts?

[stmoy]

Hi @brodybits - thank you for your input. You're right in noting that the move from .NET (C#)/vCurrent to C++/vNext will be a breaking change. However, this breaking change is to be more inclusive of C++ development and not to exclude C# development.

From an “underlying framework” point of view, you’re right that vCurrent will be replace with vNext by the end of the year. By “underlying framework”, I mean the literal guts of React Native for Windows. From an app developer point of view, it should be possible for apps to migrate their existing native code to vNext without too much hassle because vNext supports native modules written in both C++ and C#. To that end, react-native-windows vNext will support .NET and C++ components even though the guts are written in C++.

We expect to have a small support window for vCurrent, but all of our future improvements will be in vNext because it provides us with the best platform in terms of performance and enables us to keep up with changes to the core React Native platform.