# Unable to compile with .NET Native tool chain (UWP project) #18188

Open
opened this issue Feb 27, 2019 · 33 comments

Contributor

gRPC 1.19.0, C#

### What operating system (Linux, Windows,...) and version?

Windows 10 1803 (17134.590)

### What runtime / compiler are you using (e.g. python version or version of gcc)

Visual Studio Professional 2017 (15.9.6)

### What did you do?

1. Created a new UWP project that references a new .NET Standard 2.0 library.
2. Add the Grpc.Auth (1.19.0) nuget to the .NET Standard library.
3. Build with .NET Native tool chain enabled.

### What did you expect to see?

A successful build

### What did you see instead?

 1> C:\Program Files (x86)\Microsoft SDKs\UWPNuGetPackages\microsoft.net.native.compiler\2.2.1\tools\Microsoft.NetNative.targets(792,5): error : ILT0014: Failed to compile interop source code. See the build log for error details.

More specifically:

1>  Compiling interop code
1>  Compiling generated source code: C:\Program Files (x86)\Microsoft SDKs\UWPNuGetPackages\microsoft.net.native.compiler\2.2.1\tools\csc\csc.exe /noconfig @"<path>\ReproGrpc\ReproGrpc\obj\x86\Debug\ilc\intermediate\ReproGrpc.McgInterop.rsp"
1>  obj\x86\Debug\ilc\intermediate\ReproGrpc.McgInterop\ImplTypes.g.cs(630,14): error CS1593: Delegate 'NativeMethods_Delegates_grpcsharp_batch_context_create_delegate__Grpc_Core' does not take 1 arguments
1>  obj\x86\Debug\ilc\intermediate\ReproGrpc.McgInterop\ImplTypes.g.cs(1421,14): error CS1593: Delegate 'NativeMethods_Delegates_grpcsharp_request_call_context_create_delegate__Grpc_Core' does not take 1 arguments
1>  obj\x86\Debug\ilc\intermediate\ReproGrpc.McgInterop\ImplTypes.g.cs(1502,14): error CS1593: Delegate 'NativeMethods_Delegates_grpcsharp_request_call_context_call_delegate__Grpc_Core' does not take 2 arguments
1>  obj\x86\Debug\ilc\intermediate\ReproGrpc.McgInterop\ImplTypes.g.cs(2069,14): error CS1593: Delegate 'NativeMethods_Delegates_grpcsharp_composite_call_credentials_create_delegate__Grpc_Core' does not take 3 arguments
1>  obj\x86\Debug\ilc\intermediate\ReproGrpc.McgInterop\ImplTypes.g.cs(3950,14): error CS1593: Delegate 'NativeMethods_Delegates_grpcsharp_call_get_peer_delegate__Grpc_Core' does not take 2 arguments
1>  obj\x86\Debug\ilc\intermediate\ReproGrpc.McgInterop\ImplTypes.g.cs(4088,14): error CS1593: Delegate 'NativeMethods_Delegates_grpcsharp_channel_args_create_delegate__Grpc_Core' does not take 2 arguments
1>  obj\x86\Debug\ilc\intermediate\ReproGrpc.McgInterop\ImplTypes.g.cs(4548,14): error CS1593: Delegate 'NativeMethods_Delegates_grpcsharp_ssl_credentials_create_delegate__Grpc_Core' does not take 4 arguments
1>  obj\x86\Debug\ilc\intermediate\ReproGrpc.McgInterop\ImplTypes.g.cs(4658,14): error CS1593: Delegate 'NativeMethods_Delegates_grpcsharp_composite_channel_credentials_create_delegate__Grpc_Core' does not take 3 arguments
1>  obj\x86\Debug\ilc\intermediate\ReproGrpc.McgInterop\ImplTypes.g.cs(4827,14): error CS1593: Delegate 'NativeMethods_Delegates_grpcsharp_insecure_channel_create_delegate__Grpc_Core' does not take 3 arguments
1>  obj\x86\Debug\ilc\intermediate\ReproGrpc.McgInterop\ImplTypes.g.cs(4948,14): error CS1593: Delegate 'NativeMethods_Delegates_grpcsharp_secure_channel_create_delegate__Grpc_Core' does not take 4 arguments
1>  obj\x86\Debug\ilc\intermediate\ReproGrpc.McgInterop\ImplTypes.g.cs(5099,14): error CS1593: Delegate 'NativeMethods_Delegates_grpcsharp_channel_create_call_delegate__Grpc_Core' does not take 8 arguments
1>  obj\x86\Debug\ilc\intermediate\ReproGrpc.McgInterop\ImplTypes.g.cs(5422,14): error CS1593: Delegate 'NativeMethods_Delegates_grpcsharp_channel_get_target_delegate__Grpc_Core' does not take 2 arguments
1>  obj\x86\Debug\ilc\intermediate\ReproGrpc.McgInterop\ImplTypes.g.cs(5617,14): error CS1593: Delegate 'NativeMethods_Delegates_grpcsharp_completion_queue_create_async_delegate__Grpc_Core' does not take 1 arguments
1>  obj\x86\Debug\ilc\intermediate\ReproGrpc.McgInterop\ImplTypes.g.cs(5688,14): error CS1593: Delegate 'NativeMethods_Delegates_grpcsharp_completion_queue_create_sync_delegate__Grpc_Core' does not take 1 arguments
1>  obj\x86\Debug\ilc\intermediate\ReproGrpc.McgInterop\ImplTypes.g.cs(6109,14): error CS1593: Delegate 'NativeMethods_Delegates_grpcsharp_metadata_array_create_delegate__Grpc_Core' does not take 2 arguments
1>  obj\x86\Debug\ilc\intermediate\ReproGrpc.McgInterop\ImplTypes.g.cs(6732,14): error CS1593: Delegate 'NativeMethods_Delegates_grpcsharp_metadata_credentials_create_from_plugin_delegate__Grpc_Core' does not take 2 arguments
1>  obj\x86\Debug\ilc\intermediate\ReproGrpc.McgInterop\ImplTypes.g.cs(7023,14): error CS1593: Delegate 'NativeMethods_Delegates_grpcsharp_ssl_server_credentials_create_delegate__Grpc_Core' does not take 6 arguments
1>  obj\x86\Debug\ilc\intermediate\ReproGrpc.McgInterop\ImplTypes.g.cs(7206,14): error CS1593: Delegate 'NativeMethods_Delegates_grpcsharp_server_create_delegate__Grpc_Core' does not take 2 arguments
1>  obj\x86\Debug\ilc\intermediate\ReproGrpc.McgInterop\ImplTypes.g.cs(8020,14): error CS1593: Delegate 'NativeMethods_Delegates_grpcsharp_call_auth_context_delegate__Grpc_Core' does not take 2 arguments
1>C:\Program Files (x86)\Microsoft SDKs\UWPNuGetPackages\microsoft.net.native.compiler\2.2.1\tools\Microsoft.NetNative.targets(792,5): error : ILT0014: Failed to compile interop source code. See the build log for error details.
1>
1>Build FAILED.


I actually get a different error in ImplTypes.g.cs with my actual project (I think because we use version 2.0.3 of the .NET Native compiler, but the repro project is using 2.2.1)

The errors were:

2>  <path>\ilc\intermediate\Snap.WindowsUWP.Full.McgInterop\ImplTypes.g.cs(12976,9): error CS0165: Use of unassigned local variable 'metadataArray'
2>  <path>\ilc\intermediate\Snap.WindowsUWP.Full.McgInterop\ImplTypes.g.cs(13006,9): error CS0165: Use of unassigned local variable 'metadataArray'
2>  <path>\ilc\intermediate\Snap.WindowsUWP.Full.McgInterop\ImplTypes.g.cs(10955,9): error CS0165: Use of unassigned local variable 'channelArgs'
2>  <path>\ilc\intermediate\Snap.WindowsUWP.Full.McgInterop\ImplTypes.g.cs(10984,9): error CS0165: Use of unassigned local variable 'channelArgs'


Let me know if this should instead be reported against the ilc. Build log and repro project attached.

ReproGrpc.zip

repro_buildlog.txt

### stanley-cheung assigned jtattermuschFeb 27, 2019

Contributor Author

### tylersouthard commented Feb 27, 2019

 Looking at this further, it appears that the .NET Native compiler is choking on generating the code for the delegates that use types descending from SafeHandle. I emailed the .NET Native team.
referenced this issue Feb 28, 2019

### MaartenBrandemann commented Mar 22, 2019

 @tylersouthard Have you gotten any response of them?
Contributor Author

### tylersouthard commented Mar 22, 2019

 I have a Microsoft Premier Support ticket active with them. The latest response is that they have an issue filed with the project team. I'm not holding my breath.

### daltonks commented Mar 31, 2019

 I'm running into this issue now... might just port my API to something else.
Contributor Author

### tylersouthard commented Mar 31, 2019

 @daltonks I work around this issue by using a full trust component, and only referencing the gRPC nuget from that side. See https://docs.microsoft.com/en-us/uwp/api/windows.applicationmodel.fulltrustprocesslauncher and https://stefanwick.com/2018/04/06/uwp-with-desktop-extension-part-1/. Obviously, in order to use that capability, you'd have to get special dispensation from Microsoft before releasing on the store.

### Noemata commented Apr 18, 2019 • edited

 I have run into this issue as well. Given this warning: X:\Program Files (x86)\Microsoft SDKs\UWPNuGetPackages\microsoft.net.native.compiler\2.2.3\tools\Microsoft.NetNative.targets(801,5): warning : ILTransform : warning ILT0028: Found native library 'X:\xxx\obj\x86\Release\ilc\in\grpc_csharp_ext.x64.dll' with unexpected CPU architecture 'amd64', while the current build target architecture is set to 'x86'. Your application may fail to launch. Please make sure to build your application with the matching CPU architecture. The core of the problem seems to be the selection of the wrong architecture for the build target selected. It is inverted, grpc_csharp_ext.x64.dll is selected for x86 target and grpc_csharp_ext.x86.dll is selected for x64 target. This eventually leads to a dyanlink resolution failure because the wrong DLLs are selected. It seems that this problem could be resolved by having the correct DLL selected for the given build target (fix the inversion). I'm not able to find where/how this selection mechanism is put in place. I'm assuming Debug works because it resolves the dynalink at runtime, thus it doesn't need to resolve the dynalink during build.

### Noemata commented Apr 18, 2019

 I was able to work around the nuget package issue related to the wrong grpc_csharp_ext DLL being selected. Unfortunately, that did not resolve the many "MCG0007: Unresolved P/Invoke method" warnings which cause the build to ultimately fail with a "ILT0014: Failed to compile interop source code." error. It appears this form of DllImport is a problem for a UWP build (example):  [DllImport(ImportName)] public static extern void grpcsharp_shutdown(); 
Contributor Author

### tylersouthard commented Apr 22, 2019

 The latest update from Microsoft regarding the original issue (.NET Native compiler issue) is that they will have a release of their Microsoft.NETCore.UniversalWindowsPlatform nuget that fixes the issue in the next 3-4 months. I will update when I hear more.

### Noemata commented Apr 22, 2019

 Given the latest OS release has broken our Microsoft Store released build (WTF) and other apps such as Microsoft's own Galaxy Explorer on the HoloLens, 3 to 4 months is not really acceptable anymore. We're suffering through too many problems not of our making as it is. Testing seems to be a big problem at Microsoft at the moment.

### daltonks commented Apr 22, 2019

 Thanks for the update. I'm surprised they're not prioritizing this more, especially with the work being done over at https://github.com/grpc/grpc-dotnet. @JamesNK, do you think the managed GRPC client will fix these issues? Doesn't give me much faith in UWP.

### Noemata commented Apr 22, 2019 • edited

 @JamesNK Grpc version would be most welcome on the UWP side of things, but I worry his focus is ASP.Net Core. If someone can provide me with a working VS2017 solution for building Grpc, I could fix the dynalink import problem. I just don't have the time to muck with all the bits needed to create a buildable UWP version of Grpc (Python, CMake, etc., etc.,). I'm game to work through part of this with you @daltonks.

### daltonks commented Apr 22, 2019

 @Noemata Ah man, I wouldn't know where to start on that, hah 😅 It looks like the C# repo has information on how to build it, have you come across this already? https://github.com/grpc/grpc/tree/master/src/csharp
Contributor Author

### tylersouthard commented Apr 22, 2019

 @Noemata I wonder if yours is a separate issue? I've been able to use gRPC in a UWP project just fine, except for when it comes to compiling with .NET Native (for Store builds). Debug builds where we don't use the .NET Native toolchain work fine. This issue was entered to essentially track Microsoft's progress in addressing a bug with how their .NET Native compiler processes certain types that happen to be used in gRPC.

### Noemata commented Apr 22, 2019

 It is precisely the use of .Net Native that is required in our case (for Store builds). I have stated elsewhere that Debug works ("Debug builds are correct." #18789). For a commercial application, the fact that Debug builds work is largely irrelevant once you get closer to deploying to the Store. It's also been a problem, because the .Net Native toolchain tends to get ignored because Debug builds are somehow deemed sufficient?? So yes, this thread and Microsoft's tracking of it is critical to getting the Release build issue resolved. That said, changing the way dynalink imports are declared is another possible solution.

### Seikilos commented May 15, 2019 • edited

 @Noemata I wonder if yours is a separate issue? I've been able to use gRPC in a UWP project just fine, except for when it comes to compiling with .NET Native (for Store builds). Debug builds where we don't use the .NET Native toolchain work fine. This issue was entered to essentially track Microsoft's progress in addressing a bug with how their .NET Native compiler processes certain types that happen to be used in gRPC. I second @Noemata on this. We are not planing to release to store but create a LOB enterprise application which is side-loaded. Never the less, Release is still compiled with .Net Native Tool. And it fails. It might also get more confusing with Microsoft's focus on .net 5.0 with those unified concepts. They aim to support ASP.Net Core with gRCP in future, nothing is directly said about UWP.
Contributor Author

### tylersouthard commented May 15, 2019

 My intention with that comment was not to say @Noemata 's issue was not an issue, or that it wasn't related. I just wasn't sure if it actually pointed to the same underlying cause. I'm certain that the cause of the original issue was simply the fact that the .NET Native compiler has trouble processing certain types present in gRPC. I only bring it up because I've noted that my particular issue is blocked pending a .NET Native compiler update, and I wasn't sure if @Noemata 's issue was investigated to the same degree and shown with any certainty to be a .NET Native compiler bug.

### Noemata commented May 28, 2019 • edited

 @tylersouthard, the ILT0014 error when compiling gRPC is a .Net Native compiler bug. Given Microsoft is now recommending gRPC as a replacement for WCF (this was stated a few times at Build 2019), one would think this issue should be a high priority item. Unfortunately, the very limited stage time given to UWP during build 2019 suggests there are now other priorities within Microsoft. Hopefully Microsoft realizes this time around that the development community is expecting another Silverlight scenario, consequently the current optics for UWP will be dramatically improved. Microsoft exec Richard Lander said: "After .NET Core 3.0 we will not port any more features from .NET Framework. If you are a Web Forms developer and want to build a new application on .NET Core, we would recommend Blazor which provides the closest programming model. If you are a remoting or WCF developer and want to build a new application on .NET Core, we would recommend either ASP.NET Core Web APIs or gRPC (Google RPC, which provides cross platform and cross programming language contract based RPCs)." Some of us were sold on UWP, and promptly let go of WPF. Going back to WPF is a non-starter for us! Please get the messaging right this time around. Silverlight still casts a long and dark shadow.

### Noemata commented Jun 3, 2019

 It's nice that gRPC is finding its way into Microsoft documentation and is obviously a high priority item for the Azure side of Microsoft initiatives: https://docs.microsoft.com/en-us/aspnet/core/grpc/basics?view=aspnetcore-3.0 Please don't forget about .Net Native and UWP.

### Seikilos commented Jun 3, 2019

 It's nice that gRPC is finding its way into Microsoft documentation and is obviously a high priority item for the Azure side of Microsoft initiatives: https://docs.microsoft.com/en-us/aspnet/core/grpc/basics?view=aspnetcore-3.0 Please don't forget about .Net Native and UWP. Except it is likely to be dead in 5.0 and merged with the Win32 binaries.

### Noemata commented Jun 5, 2019 • edited

 @Seikilos, I hope you are wrong about UWP's standing, but reading the tea leaves and having previous exposure to how things work at Microsoft, I'm less hopeful. I have tried to communicate to the .Net Compiler folks that the compiler has become less stable over the last few releases. I am starting to think there is no regression testing at all of late. Here's a really good example, this is an MSDN article published in 2016. This code used to compile for Release: https://msdn.microsoft.com/en-us/magazine/mt742869.aspx The above sample still compiles under debug, but exhibits similar Release build issues that gRPC has when building for Release. Really, how is it possible to miss this sort of thing? When old MSDN article code doesn't compile anymore, code that we as developers regard as gospel, how are we supposed to have confidence in either the tooling or direction. I expect old API's and code constructs to get more stable, not less. The .Net Native compiler team needs to be exposed to a week long Linus Torvalds rant. Then they might have some sense of the pain we get to feel as a result of their work.

### tommcdon commented Jun 6, 2019

 ..the ILT0014 error when compiling gRPC is a .Net Native compiler bug... Thank you for your feedback. The issue is now fixed and will be shipping in a future UWP update. We are deeply appreciative for your commitment to help us build better products, and we hope this fix improves your experience with our tools and technologies. UWP release notes are published here: https://github.com/microsoft/dotnet/blob/master/releases/UWP/net-native2.2/README.md, and we will include this issue in the notes when we release the update.

### SimoneBWS commented Jun 28, 2019

 I'm running into this issue now.. Does anyone know when the fix will be released? I love UWP, but it need for a greater improvements-alignment-stability from Microsoft!

### Noemata commented Jun 28, 2019

 We've been waiting for this fix for awhile. Please provide some ETA information.

### tommcdon commented Jun 29, 2019

 I'm running into this issue now.. Does anyone know when the fix will be released? We've been waiting for this fix for awhile. Please provide some ETA information. @SimoneBWS @Noemata We do not yet have a published release schedule. Please stay tuned and we will have more info. I love UWP, but it need for a greater improvements-alignment-stability from Microsoft! @SimoneBWS Are you running into other issues that we are not aware of? If so, please email us directly at dotnetnative@microsoft.com with an ILCRepro (see https://github.com/dotnet/core/blob/master/Documentation/ilcRepro.md for instructions).

### andygikling commented Jul 27, 2019

 Same issue here... @tommcdon ?

### tommcdon commented Jul 29, 2019

 @andygikling @Noemata we are working with the store team to finalize our release date.

### andygikling commented Aug 5, 2019 • edited

 @tommcdon thanks for the response. Per @Noemata 's comments, it's literally unbelievable to me that Microsoft is now using Github as a main source of quality control for many of their flagship products. They used to do this in house, now they just push nonsense software and ask me to waste my afternoon fighting their bugs and poor quality! Oh, but I'm a part of the "community" on Github and I get to work on open source projects - no, I'm doing your damn job Microsoft and I'm sick of it! Microsoft, your software quality has been on a downhill slide for the past 5 years! It has become so brutally obvious. Stop trying to make more money with a million idiot products nobody wants or needs. Instead, polish the stuff you have and quite wasting my time... god these problems are endless in C# / UWP land! I used to enjoy C# / WPF... what a train wreck UWP has been. I'm very, very frustrated...

### noypi commented Aug 10, 2019 • edited

 @andygikling @Noemata we are working with the store team to finalize our release date. @tommcdon What do I need to update once you guys are done? should I upgrade IDE? is community edition supported?

### MattWhilden commented Aug 23, 2019

 6.2.9 is now available on Nuget. Certainly let us know how it goes.

### noypi commented Aug 30, 2019

 6.2.9 is now available on Nuget. Certainly let us know how it goes. I can now build a release for UWP. But there are exceptions that are very difficult to understand. My overall comment, compiling to native is making it hard for development. What is working in debug mode is no longer the same on release mode. Yes it is frustrating, from the 3rd world country - the registration fee is quite high - and then I ended up not publishing my app to store.

### MattWhilden commented Aug 30, 2019

 @noypi Sorry to hear it's still causing you trouble. If you can describe your issues in a bit more detail it's possible I can help you get unblocked. A way for me to reproduce the error locally is ideal but even exception messages and stacks go a long way. I presume the maintainers of this repo don't mind us chatting here but I'm also reachable at dotnetnative@microsoft.com.