Cannot build UWP app in ARM64: exit code 1102

[tipa]

Building ARM64 packages works for most of my UWP apps, but one of them (the largest project) fails with this error:

2>  Processing application code
2>  Computing application closure and generating interop code
2>    Loading 158 modules...
2>    Generating code...
2>    Interop code generated.
2>  Generating serialization code
2>  Compiling interop code
2>  Generating System.Reflection.DispatchProxy proxy code.
2>  Cleaning up unreferenced code
2>  Generating native code
2>  Generating fixups for native code
2>C:\Program Files (x86)\Microsoft SDKs\UWPNuGetPackages\microsoft.net.native.compiler\2.2.7-rel-27913-00\tools\Microsoft.NetNative.targets(801,5): error : ILT0005: 'C:\Program Files (x86)\Microsoft SDKs\UWPNuGetPackages\runtime.win10-arm64.microsoft.net.native.compiler\2.2.7-rel-27913-00\tools\ARM64\ilc\tools\link\link.exe @"pathtoproj\obj\ARM64\Release\ilc\intermediate\linkargs.MyApp.rsp"' returned exit code 1102
========== Build: 1 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
A package has been successfully built for Release (x86).
A package has been successfully built for Release (x64).
A package has been successfully built for Release (ARM).
========== Package: 3 succeeded, 1 failed ===========
========== App Bundle: 1 succeeded, 1 failed ===========

[dpaulino]

I have this same issue with Nightingale. @tipa have you found any workarounds? Also, is your build failing on a CI pipeline or are you building locally on your machine? jenius-apps/nightingale-rest-api-client#99

[tipa]

No I haven't found any workarounds, I gave up trying and don't build ARM64 variants for my apps any more.

[dpaulino]

@tipa I did some investigations and it looks like the issue is related to low memory. See this comment jenius-apps/nightingale-rest-api-client#99 (comment)

[mfeingol]

I've been having the same issue with my app, and I recently upgraded to 6.2.11 to see if that helps with this problem. Unfortunately, the build process still fails on ARM64:

3>C:\Users\mfeingol\.nuget\packages\microsoft.net.native.compiler\2.2.9-rel-29512-01\tools\Microsoft.NetNative.targets(805,5): error : /c/Users/mfeingol/.nuget/packages/runtime.win10-arm64.microsoft.net.native.compiler/2.2.9-rel-29512-01/tools/ARM64/ilc/tools/link/link: missing operand after '��/'
3>C:\Users\mfeingol\.nuget\packages\microsoft.net.native.compiler\2.2.9-rel-29512-01\tools\Microsoft.NetNative.targets(805,5): error : Try '/c/Users/mfeingol/.nuget/packages/runtime.win10-arm64.microsoft.net.native.compiler/2.2.9-rel-29512-01/tools/ARM64/ilc/tools/link/link --help' for more information.
3>C:\Users\mfeingol\.nuget\packages\microsoft.net.native.compiler\2.2.9-rel-29512-01\tools\Microsoft.NetNative.targets(805,5): error : ILT0005: 'C:\Users\mfeingol\.nuget\packages\runtime.win10-arm64.microsoft.net.native.compiler\2.2.9-rel-29512-01\tools\ARM64\ilc\tools\link\link.exe @"C:\Operations\Build\Home\Sideroads\Source\Sideroads.Windows\obj\ARM64\Release\ilc\intermediate\linkargs.Sideroads.rsp"' returned exit code 1

Please let me know what sort of diagnostics might help.

[tommcdon]

Please share a structured msbuild log to [email protected]:

• MSBuild Log Viewer: http://msbuildlog.com/
• VS project system extension: https://marketplace.visualstudio.com/items?itemName=VisualStudioProductTeam.ProjectSystemTools

[mfeingol]

Thanks for following up, @tommcdon. Here's a log:

msbuild.binlog.zip

The file seems small, so I'm not sure it has the granularity you need. Let me know if I need to re-run with increased verbosity.

[tapmatix]

I ran into the exact same problem. Let me know if more logs could help, or if there is any workaround to try.

[tommcdon]

The error message in the msbuild log is:

LINK : the 32-bit linker (C:\Users\mfeingol\.nuget\packages\runtime.win10-arm64.microsoft.net.native.compiler\2.2.9-rel-29512-01\tools\ARM64\ilc\tools\link\link.exe) ran out of heap space and is going to restart linking with a 64-bit linker

In the 6.2.11 release, we added a compilation flag to disable symbols on ARM64. This saves memory and as a side-effect may unblock the build. To try it out, add <NoLinkerSymbols>true</NoLinkerSymbols> to the to the relevant ARM64 property groups in your csproj files.

It may also be possible to resolve the issue by reducing the input into the compiler. I’m not sure if we have shared these workarounds in the past, but these have historically been useful in helping to reduce the memory footprint to the compiler, which will also increase compilation speed:

Compiler flags

There are a wide range of flags available but here’s a couple that may help out:
<ShortcutGenericAnalysis>true</ShortcutGenericAnalysis>- Can help stop runaway analysis of generic types and reduce overall generation requirements.
<UseDotNetNativeSharedAssemblyFrameworkPackage>false</UseDotNetNativeSharedAssemblyFrameworkPackage> - Eliminates one of the linking boundaries the compiler has to fight with. I actually suspect turning this off will make things worse not better but whole program optimizers are hard to reason about but rebuilds are cheap enough to try.
Runtime Directives
There is a default.rd.xml file that provides "Runtime Directives" to the .NET Native compiler. The overall syntax of the file is also included in the reading above. The default config is the following, which may be leading to including "too much" metadata and code into the .NET native compiler engine:
<Assembly Name="*Application*" Dynamic="Required All" />
Removing the directive but still have a working application may take some time iterating through a series of directives to try. There’s two approaches that have tradeoffs, so I’ll describe both and let you decide if either methodology suits you. Roughly here’s what the two workflows look like:

Start from nothing.

1. Remove the special *Application* directive
2. Build the app
3. If the build fails, email us, else…
4. Test the app and see if you hit any runtime errors
5. If you do you’ll need to look at the error location and see if adding some directives can help then head back to (2).
6. If you find no errors, you’re done! Hooray!

Start from everything

1. Remove the special *Application* directive
2. Get a list of the full set of dlls for your project, for example by inspecting here: obj[architecture]\Release\ilc\in
3. For each dll, add a Dynamic directive. They’ll look like: <Assembly Name="ASSEMBLYNAMEWITHOUTEXTENTION" Dynamic="Required All"/>
4. Comment out some subset of these libraries
5. Build the app
6. If the build fails again in RHBIND go to (4)
7. Test the app and see if you hit any runtime errors
8. If you do you’ll need to look at the error location and see if adding some directives can help then head back to (5)
9. If you find no errors, you’re done! Hooray!

These articles provide some useful background info:

• https://devblogs.microsoft.com/dotnet/net-native-deep-dive-dynamic-features-in-static-code/
• https://docs.microsoft.com/en-us/dotnet/framework/net-native/runtime-directives-rd-xml-configuration-file-reference
• https://docs.microsoft.com/en-us/dotnet/framework/net-native/runtime-directive-policy-settings

[MagicAndre1981]

I get error code 1105. What does this mean?

I always get this when the source is on a network share, if the source is on local drive compiling works fine.