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

In a mixed c++/c# project, enabling "Compile with .NET Native tool chain" results in black screen without useful debug information #6332

Closed
exotexot opened this issue Oct 25, 2020 · 19 comments

Comments

@exotexot
Copy link

I'm having troubles with my react-native-windows app submission to the microsoft store due to app certification prbolems. As described in this issue: #4516
there are problems, apparently running a mixed c++ / c# project, with the submission process. A solution to fix initial app certificaiton you are required to enable .net native-ization of the code.

After adding the solution mentioned here: #4516 (comment), I cannot run my app anymore. The app literally gets stuck with a black screen without errors being thrown in either terminal console or visual studio debug output. I tried using 2.2.3 and 2.2.8-rel-28605-00, added all Exception flags to be thrown, but literally nothing happens. Without having the fix applied, I can run and build my app without problems. That seems super strange to me but must somehow be related to the .net native-ization. Any ideas how this could be related?

System:
OS: Windows 10 10.0.19041
CPU: (8) x64 Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz
Memory: 9.30 GB / 15.97 GB
Binaries:
Node: 12.9.1 - C:\Program Files\nodejs\node.EXE
Yarn: 1.22.4 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
npm: 6.10.2 - C:\Program Files\nodejs\npm.CMD
Watchman: Not Found
SDKs:
Android SDK: Not Found
Windows SDK:
AllowDevelopmentWithoutDevLicense: Enabled
AllowAllTrustedApps: Enabled
Versions: 10.0.18362.0, 10.0.19041.0
IDEs:
Android Studio: Not Found
Visual Studio: 16.7.30611.23 (Visual Studio Community 2019)
Languages:
Java: Not Found
Python: Not Found
npmPackages:
@react-native-community/cli: ^4.13.0 => 4.13.0
react: 16.11.0 => 16.11.0
react-native: 0.62.2 => 0.62.2
react-native-windows: ^0.62.14 => 0.62.14

npmGlobalPackages:
react-native: Not Found

@exotexot exotexot added the bug label Oct 25, 2020
@ghost ghost added the Needs: Triage 🔍 New issue that needs to be reviewed by the issue management team (label applied by bot) label Oct 25, 2020
@chrisglein
Copy link
Member

The app literally gets stuck with a black screen without errors being thrown in either terminal console or visual studio debug output.

In the other issue you included a winrt error. Are you no longer seeing that? Are there any thrown winrt originate errors that happen during startup that seem suspicious? Based on your comment "added all Exception flags to be thrown, but literally nothing happens" I'm guessing no?

How possible is it to share your app with us so we can help take a deeper look? We've had this scenario work, but there must be some difference that's causing your experience to differ and we want to get to the bottom of that. For example \packages\E2Etest in this repo.

@chrisglein chrisglein added Needs: Author Feedback The issue/PR needs activity from its author (label drives bot activity) and removed Needs: Triage 🔍 New issue that needs to be reviewed by the issue management team (label applied by bot) labels Oct 26, 2020
@exotexot
Copy link
Author

I forgot to mention, the blank screen / no debug info only happens in Release mode. When building in Debug mode, I'm getting this error:

Exception thrown at 0x00007FFA4BB73E49 (KernelBase.dll) in cateurope.exe: WinRT originate error - 0x80131522 : 'System.TypeLoadException: Could not load type 'Internal.Runtime.Augments.EnvironmentAugments' from assembly 'System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e'.
at System.Environment.get_CurrentManagedThreadId()
at System.Linq.Enumerable.Select[TSource,TResult](IEnumerable1 source, Func2 selector)
at Microsoft.ReactNative.Managed.ReactPackageBuilderExtensions.InitAttributedModules()
at System.Lazy1.CreateValue() at System.Lazy1.LazyInitValue()'.
onecore\com\combase\winrt\error\restrictederror.cpp(1016)\combase.dll!00007FFA4CCF0243: (caller: 00007FFA4CCFE7A9) ReturnHr(1) tid(1d08) 8007007E The specified module could not be found.

The program is crashing then with this error:

The program '[4116] cateurope.exe' has exited with code 3 (0x3).
Activation of the Windows Store app 'CivilAviationTrainingGmbH.CATeLearning_4bs8rbspejphm!App' failed with error 'Operation not supported. Unknown error: 0x80040905'.

This may be the case as the .net toolchain only applies in Release mode:

true
2.2.8-rel-28605-00

How possible is it to share your app with us so we can help take a deeper look?
Would you want the entire react-native project or would the appxbundle file suffice?

@ghost ghost added Needs: Attention 👋 An issue that had been tagged "Needs: Author Feedback" has received activity (label applied by bot) and removed Needs: Author Feedback The issue/PR needs activity from its author (label drives bot activity) labels Oct 26, 2020
@asklar
Copy link
Member

asklar commented Oct 27, 2020

@exotexot if it's possible for you to share the source that would be easiest.
Just to double check - are you using any 3rd party libraries? If so, are those WinRT components or desktop .net framework libraries?

@exotexot
Copy link
Author

I'll prepare a repo for you!

I'm using several react-native modules, such as AsyncStorage (c++), Device Info (c#), Senstive Info (c#), WebView (c++), Static Server (c#), and RNFS(c++) which to my understanding are all winRT components.

@exotexot
Copy link
Author

exotexot commented Oct 27, 2020

Hey @chrisglein @asklar

I was able to narrow down the problem to the .net native tool chain for sure.

In this example repo: https://github.com/exotexot/uwpcs I've made a clean react-native init using react-native (0.62.2 - as I'm on this version and cannot update at the moment) and react-native-windows (0.62.14) and a c# dependency that I'm using: https://github.com/react-native-device-info/react-native-device-info

This repo also has the fix suggested here: #4516 (comment)

<UseDotNetNativeToolchain Condition="'$(Configuration)'=='Release'">true</UseDotNetNativeToolchain>
<DotNetNativeVersion >2.2.8-rel-28605-00 </DotNetNativeVersion>

You will see that no exceptions are being thrown, just some warnings, which I ignored. Regarding the missing rd.xml file (https://social.msdn.microsoft.com/Forums/en-US/19568d89-bc63-498b-9459-a1a694fcbdc5/uwpnative-compiler-missing-runtime-directives-file?forum=wpdevelop said it wont fix anything).

Running this repo in release mode will get you the blank screen issue.
Renning this repo in debug mode will get you the aforementioned KernelBase.dll error.
If you're feeling lazy you can go back to the second commit in my repo to have a version without .net nativization enabled.

However, this issue lead me to this source: https://techcommunity.microsoft.com/t5/windows-dev-appconsult/could-not-load-file-or-assembly-8216-system-private-corelib/ba-p/317201 which says:

This error occurs because Microsoft Store no longer accepts packages with mixed UWP and Desktop .NET binaries that have not been created with the proper packaging project ( Visual Studio Packaging Project ). This is to ensure the UWP binaries get the proper .NET native compile in the cloud (which is not applicable to the Desktop .NET binaries).

I'm a complete noob concerning Visual Studio but it feels like the .native compilation is somehow not doing its job.

EDIT:
Just to keep you posted: as suggested here dotnet/runtime#43823 I've opened an vs-developer issue here: https://developercommunity2.visualstudio.com/t/In-a-mixed-UWP-cc-project-enabling-/1234699

@exotexot
Copy link
Author

In the initially referenced issue, they point to #3838 which concludes with:

“ I dont think its clear that this baiscally stops any C# app with custom native modules from shipping to the store. (Since .Net Native is a requirement for shipping to the store).

This kind of snuck under the radar.”

Will try the solution mentioned in this thread later.

@jonthysell
Copy link
Contributor

Since you're building on RNW 0.62.14, can you try adding the following to your app's vcxproj:

<PropertyGroup Label="ReactNativeWindowsProps">
    <ReactNativeWindowsDir Condition="'$(ReactNativeWindowsDir)' == ''">...</ReactNativeWindowsDir>
+   <ConsumeCSharpModules>true</ConsumeCSharpModules>
</PropertyGroup>

I just backported some fixes for C++ apps consuming C# modules (making sure the correct version of .NetNative is used) that's behind that ConsumeCSharpModules property.

@asklar
Copy link
Member

asklar commented Oct 28, 2020

@jonthysell thanks for jumping in. I was able to repro was @exotexot is seeing in their project, and adding the ConsumeCSharpModules property doesn't make the problem go away.

The C# native module being used (RNDeviceInfo) is written with attributes so reflection will be needed. It isn't clear to me if it is necessary or how to add a rd.xml to the library to allow the necessary types to be reflected on.

There is also a bug filed against DevDiv for this that @SvetBonev asked RNW team to take a look at.
@jonthysell could you take on this investigation?

@exotexot
Copy link
Author

I also couldnt spot any difference. Still same behaviour in Debug and Release builds. I'm not really sure about the .rd.xml file, but I've added this file to my node_modules\react-native-device-info\windows\RNDeviceInfo\Properties without any change.

RNDeviceInfo.rd.xml

<?xml version="1.0" encoding="utf-8" ?>
<Directives xmlns="http://schemas.microsoft.com/netfx/2013/01/metadata">
	<Application>
		<Assembly Name="*Application*" Dynamic="Required All" />
	</Application>
</Directives>

@asklar could you try and explain the issue in a more general way? The reason I'm asking is, that there is already a working c++PR for device-info. But I do have a not-so-well-maintained react-native-static-server fork (https://github.com/exotexot/react-native-static-server/tree/windows/windows/FPStaticServer), which I need for my production app. But there is no sign of any development in for this module, let alone a c++ version.

@asklar
Copy link
Member

asklar commented Oct 28, 2020

@exotexot there are two ways to build native modules with C#, "the old way" relies on attributes like [ReactModule] etc. and depends on reflection to be able to find and activate types. This is tricky to get right with .net native (C# apps need to explicitly opt in assemblies/types to be reflect-able). The mixed language scenario of consuming C# from C++ has historically been not-so-well documented (I mean outside of RNW), so while we know how to consume a C# library from C++ with .net native (the property Jon mentioned helps with that), it is not clear to me how to set up the runtime directives that allow reflection to take place: does one just drop a rd.xml file with the right syntax and magic is supposed to happen? does one need to mention the rd.xml file in a special way in the project file? is there a ui in VS where this is specified? (doesn't seem to be the case).
The new one relies on code generation and so it avoids the complexities of .net native / RD

@exotexot
Copy link
Author

Ah I see. Could you maybe share a react-native module that uses a c# implementation which is easier to consume from c++ with .net native?

@asklar
Copy link
Member

asklar commented Oct 28, 2020

normally we've been advocating for public modules to be written in C++ (because writing them in C# has these types of hard-to-debug problems). Maybe @chrisglein or @stmoy know off the top of their heads if there are any C# modules that work well. For reference the samples in the react-native-windows-samples repo as well as the SampleLibraryCS here should have some but those may not be "real world" enough for your purposes, let us know

@exotexot
Copy link
Author

exotexot commented Oct 29, 2020

Sure, I do understand that there are benefits of having modules written in c++. However, we've been developing our app for months now, testing in Debug and Release mode. As you said, may be due to improper documentation, we werent aware of the implications and potential pitfalls of using c++ and c# modules. Also "weird" is that there is no visible option in recent VS versions to enable .net native toolchain in the VS UI and we're required to find out that we need to add a few lines to our vcxproj file, which allows us to submit our app to the microsoft store but ends up breaking it. This is just a bit weird to fathom.

And really, the worst part is, that apart from submitting the app to the store, my only option is to sideload the app, which doesnt even install the dependencies and certificates automatically using the appxbundle. So how much crappier can the developing and publishing experience be? Am I really required to tell my customers, that the only way to install the app right now, is through a powershell script? Wow.

@asklar
Copy link
Member

asklar commented Oct 29, 2020

Hi @exotexot, thanks for your patience, our team is committed to trying to help you get unblocked, please realize that our direct team doesn't own all of the technologies needed to build apps (like the store, the certification kit, visual studio, the compiler, .net and .net native, etc.) so finding out answers to issues in interacting with these technologies might take a bit of time on our side.

As far as the checkbox for enabling .net native in Visual Studio, that only shows up when the app is written in C#, not when a library is written in C#.
image

As far as deployment, you shouldn't need to run the powershell script to sideload the app, this is only for the developer inner loop. There are options depending on your scenario (enterprise, consumer, education etc.) on how to publish the app outside the store. Here's a doc I've been putting together that should go live when we publish 0.64, the deployment piece might be esp relevant:
https://microsoft.github.io/react-native-windows/docs/next/native-code#distribution

@exotexot
Copy link
Author

Hi @asklar. Do you think it would make a difference If I have the main app uses the cs template? Can I consume c++ modules from a c# main app?

Regarding distribution: As Microsoft Store is not an option, I looked into the app-installer, which looks promising, as it seems to reference dependencies in its xml-based .appinstaller file. I know this kind of shifts the focus of this issue, however, maybe people relate as this is a problem generally related to distributing ones app. I sort of need alternatives now. Using the App-Installer still leaves me with code-signing issues.

I still havent figured out code-signing with windows apps. As I don't want my users to use the powershell script, and can't really expect them to successfully install my self-signed certificate, as double-clicking the .cer file, choosing "Local Machine" and then "Trusted People" store may exhaust their dedication. But understandably though. As a software-consumer, I want to double click and install an app, without caring about certificates or dependencies. However, I learned that I can buy a "Extended Validation Code Signing" Certificate, which make my apps somehow trustworthy, outside the scope of the microsoft store. Yet, this source: https://docs.microsoft.com/en-us/windows/msix/app-installer/installing-windows10-apps-web#signing-the-app-package says:

For users to install your app, you will need to sign the app package with a trusted certificate. You can use a third party paid certificate from a trusted certification authority to sign your app package. If a third party certificate is used, the user will need to have their device in either sideload or developer mode to install and run your app.

Am I correct, that even if I get the EV Code Signing Certificate, that users still manually go to Settings > Update & Security > For Developers and select “Developer mode”? I mean, this is just not the user experience that I want for my users.

@asklar
Copy link
Member

asklar commented Nov 3, 2020

regarding your first question, yes you can consume C++ modules from a C# app. Making the app C# could potentially solve some of the problems you are seeing since VS will allow you to turn on using .net native for the app.

As to your second question, I'm not sure so I will have to defer to someone who knows more about certificates, but I would not expect customers to have to turn on developer mode, that sounds unreasonable. Tagging @jonwis in case he knows more about this aspect or whom to ask.

@exotexot
Copy link
Author

exotexot commented Nov 3, 2020

Wow okay. I wasnt aware that one could consume c++ from a c# app. I thought it was just to other way round. After using the cs template I was able to see the Compile with .NET Native tool chain and could build without issues and was also able to submit to the Microsoft Store. Hence the the issue with the certificate is resolved as it is no longer needed.

So at least one can tell that the .net native compiler can do its job properly! I'm also updating the issue here: https://developercommunity2.visualstudio.com/t/In-a-mixed-UWP-cc-project-enabling-/1234699 hoping that there may be a fix for the issue in future.

@asklar asklar changed the title In a mixed c++/c# project, enabling "Complie with .NET Native tool chain" results in black screen without useful debug information In a mixed c++/c# project, enabling "Compile with .NET Native tool chain" results in black screen without useful debug information Nov 9, 2020
@asklar asklar added Area: Developer Experience and removed Needs: Attention 👋 An issue that had been tagged "Needs: Author Feedback" has received activity (label applied by bot) labels Nov 9, 2020
@asklar asklar added this to the 0.65 milestone Nov 9, 2020
@jonthysell
Copy link
Contributor

Unfortunately the inability of C++ apps to use the rd.xml to enable reflection with .NetNative for C# libs is an issue that we don't have a answer for yet. I'm tracking the issue here: #6473

@jonthysell
Copy link
Contributor

I know this was opened first, but I'm closing this as a dupe of #6473 where we're tracking the root cause.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants