C++/WinRT-based apps consuming C# native modules (which use reflection) cannot use .NetNative, and therefore may be unable to actually ship

[jonthysell]

This repros both in RNW 0.62, 0.63, and seems to be a problem with Visual Studio and/or the C++/WinRT toolchain.

RNW 0.62 uses reflection to implement the "attribute-based" C# implementations for both ReactModule and AttributedViewManager. A C# native module that uses these "attribute-based" implementations (as recommended) will only completely work with a C# based app.

Everything will compile and run fine for Debug. At runtime, the reflection will work to discover the ReactModules and AttributedViewManagers.

When building in Release, with .NetNative enabled, all of the reflection metadata will be stripped from the final binaries, so everything will compile, but at runtime the reflection will fail to discover the modules / view managers. The supported solution is to add a Runtime Directives file to your app, to direct .NetNative to not strip out the metadata.

However, only C# apps support adding this runtime directive file. Just adding the file to a C++/WinRT app will cause a build break when .NetNative tries to run.

One workaround is to not use .NetNative altogether, even on Release builds. While it's supposed to be required to use .NetNative to publish an app on the Store, it's not actually enforced. However, this does mean that your app will not work at all in Windows 10X, which will not run apps that use C# if it hasn't been .NetNative-ized.

In RNW 0.63 this is partially mitigated by the switch from reflection to code-gen. C# native modules written using the attribute-based ReactModule do not rely on runtime reflection, as so work fine with .NetNative. However, AttributedViewManager was not converted to code-gen, so the issue remains.

If it's not confusing enough, imagine you're a community module that needs to support multiple versions of RNW.

If you are writing a C# native module and want to support the full matrix of C++/C# apps and 62/62 with one shared set of code - the only workaround is to avoid using any reflection in your implementation, which means manually implementing the low-level ABI for your module (implementing the IViewManager interfaces directly like C++ developers do for view managers, and calling the various module builder APIs, see Naitve Modules Advanced docs for native modules).

[dannyvv]

Note: In 0.63, even when CodeGen is used, For the serialization cases there are still fallback codepaths that rely on reflection. For serialization the codegen is a best effort since due to polymorphism and generics not all possible types used can be guaranteed to be visible during codegen.

[jonthysell]

Note: In 0.63, even when CodeGen is used, For the serialization cases there are still fallback codepaths that rely on reflection. For serialization the codegen is a best effort since due to polymorphism and generics not all possible types used can be guaranteed to be visible during codegen.

I didn't realize this and it's good to call out, in case other people start seeing issues.

[jonthysell]

This was hit by a customer trying to consume Device Info (c#), Senstive Info (c#), and Static Server (c#) (see #6332) being unable to pacakage for store distribution, and their workaround was to switch their app to C#.

[asklar]

If we can't find a fix let's document this - also related: #6539