Can't build native UWP app. ILC.exe, always a 32-bit image, fails with: Internal compiler error: Exception of type 'System.OutOfMemoryException' was thrown. #5905
Comments
We don't have a 64-bit version of ILC.exe, unfortunately. Could you try placing This will try to shortcut analysis of generic code (if that's the problem) and might fix the issue for you. We recommend re-testing your app since it might make the analysis miss reflection patterns or serialization uses (it's possible to manually fix those later with RD.XML if that happens) and shouldn't be a big problem. |
I'll try that shortly, thanks. But, re:
Perhaps note that in the package description, somehow? The naming |
The |
@MichalStrehovsky I just got around to trying this with the option you mentioned above, I looked for information about this ShortcutGenericAnalysis option, but I can't find anything about it — Google has no relevant hits other than this same issue. Is ShortcutGenericAnalysis an official setting, or a private setting for troubleshooting issues such as this one? FWIW, while building I was closely watching memory usage for both the |
Glad you got unblocked. I think the
Ilc.exe has no right to use that much memory because it doesn't do that kind of work. The only legit use case of Ilc.exe needing more than 3 GB of memory is when someone puts hundreds of megabytes of data into managed resources. Ilc.exe unfortunately maps all of it into its address space and things get pretty tight. We might end up shipping a 64bit version of it, but just because of that. |
Has any progress been made on a 64-bit version of ilc? I'm on VS 16.2.0 with UWP 6.2.8 and I am receiving the same error as the OP. However, all the
I assume these are related to missing entries in <Namespace Name="Ewn" Serialize="All" /> |
@gtbuchanan Compilation failures are never a manifestation of missing RD.XML entries. This looks like a bug. Can you reach out to dotnetnative at microsoft com? We're better equipped to help there. |
I am hitting a similar problem as well when building in Azure Pipelines. I have all these flags set in my .csproj:
The error message is not mentioning "OutOfMemoryException" however:
Anything else that I could try? |
I'm trying to build a UWP unit test app in Release mode using the Compile with .NET Native tool chain option enabled. My UWP app's minimum and target versions are both set to Windows 10 build 16299. I'm using Visual Studio 15.7.3, and the build always fails because ILC.exe runs out of memory:
I could see that the ILC.exe executable is a 32-bit image and isn't able to take advantage of most of the 32GB memory available on my box. ILC.exe failed after allocating about 3.4GB memory.
I tried to get Visual Studio to invoke a 64-bit ILC.exe using in each of the following ways, but ILC.exe is, according to Process Explorer, always running as a 32-bit process.
I tried adding
<UseNativeEnvironment>true</UseNativeEnvironment>
to my UWP project's default<PropertyGroup>
element. I found a mention of this in relation to Visual C++, so I might have been barking up the wrong tree for a C# app on UWP.I tried adding
<Use64BitCompiler>true</Use64BitCompiler>
to my UWP project's default<PropertyGroup>
element. I had found this mentioned at Net Native compilation fails with Out of Memory (Xamarin/UWP) #5604.I tried explicitly referencing the package
runtime.win10-x64.Microsoft.Net.Native.Compiler
v2.1.8 in my UWP project. The package description says:While it does appear that the correct package folder is referenced and a
tools\x64\ilc\ilc.exe
image is being executed by Visual Studio, the ILC.exe process remains a 32-bit process even despite thex64
claimed by parent folder naming. Here's what Process Explorer shows:Am I doing something wrong?
Or is the ILC.exe that is shipped as part of
runtime.win10-x64.Microsoft.Net.Native.Compiler
actually a 32-bit program image and not a 64-bit program image? And if it is actually a 32-bit program image, is that by design, or an oversight?How can I get my UWP app building with the native tool chain? Thank you.
The text was updated successfully, but these errors were encountered: