ImageSharp-rc1 fails to build on UWP Release ARM

[Sergio0694]

Possibly related to #987 and #828

Prerequisites

• I have written a descriptive issue title
• I have verified that I am running the latest version of ImageSharp
• I have verified if the problem exist in both DEBUG and RELEASE mode
• I have searched open and closed issues to ensure it has not already been reported

Description

Building a UWP app in Release ARM fails to build when using ImageSharp-rc1, and the UWP compiler version 6.2.10 (latest). Downgrading to -beta007 works for now.
Here's the issue I'm getting:

ILT0005: 'C:\Users\Sergio.nuget\packages\runtime.win10-arm.microsoft.net.native.compiler\2.2.8-rel-28605-00\tools\ARM\ilc\Tools\nutc_driver.exe @"C:\Users\Sergio\source\repos\ImageSharpRepro\ImageSharpRepro\obj\ARM\Release\ilc\intermediate\MDIL\ImageSharpRepro.rsp"' returned exit code -1073741819 ImageSharpRepro

Building Release x86, x64 and ARM64 works fine 🤷‍♂️

Pinging @MattWhilden for his infinite .NET Native knowledge and wisdom 🧙‍♂️

Steps to Reproduce

• Create a new UWP project (19041 target, 17763 minimum)
• Add the ImageSharp-rc1 package
• (Try to) build in Release ARM

System Configuration

• ImageSharp version: ImageSharp-rc1
• Other ImageSharp packages and versions: .NETCore.UniversalWindowsPlatform 6.2.10
• Environment (Operating system, version and so on): Windows 10 x64 19041.264

[MattWhilden]

Thanks for tagging me. I've opened an issue with the optimizer team and they should take a look at it in the near future. The ID in our internal DB is 1130988 in case that's useful when talking to other .NET folks.

[MattWhilden]

Oh, forgot to mention. I haven't played with it but I'd be surprised if you couldn't work around the issue by disabling compiler optimizations. It's hard to narrow down what's problematic immediately but something like this in Properties\Default.rd.xml might get you unstuck:

<Assembly Name="SixLabors.Core.dll" DoNotOptimize="true" DoNotInline="true" />
<Assembly Name="SixLabors.ImageSharp" DoNotOptimize="true" DoNotInline="true" />

[Sergio0694]

Hey @MattWhilden - that's great, thank you for looking into this! 😊

I tried your .rd.xml fix and it did in fact build successfully! If it helps, I got this output:

1>------ Rebuild All started: Project: ImageSharpRepro, Configuration: Release ARM ------
1>  ImageSharpRepro -> C:\Users\Sergio\source\repos\ImageSharpRepro\ImageSharpRepro\bin\ARM\Release\ImageSharpRepro.exe
1>  Processing application code
1>C:\Users\Sergio\source\repos\ImageSharpRepro\ImageSharpRepro\Properties\Default.rd.xml(26): warning : ILTransform : warning ILT0027: Assembly name 'SixLabors.Core.dll' failed to bind.
1>  Computing application closure and generating interop code
1>    Loading 59 modules...
1>    Generating code...
1>    Interop code generated.
1>  Compiling interop code
1>  Generating System.Reflection.DispatchProxy proxy code.
1>  Cleaning up unreferenced code
1>  Generating native code
1>  Generating fixups for native code
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========

In particular, that warning sounds interesting:

warning : ILTransform : warning ILT0027: Assembly name 'SixLabors.Core.dll' failed to bind.

At this point I think I'll just drop the ARM builds entirely for now though, as they're not really used anywhere anyways (there are no Windows 10 ARM32 devices, as far as I know), and I'd rather not lose performance on x86, x64 and ARM64 due to those skipped optimizations/inlinings.

So glad this issue is only happening on ARM32! 😄

[MattWhilden]

Ah, maybe I misremembered which binaries get pulled in. Might be a completely spurious. :-D

[JimBobSquarePants]

SixLabors.Core.dll

@Sergio0694 That binary shouldn't exist now!

[JimBobSquarePants]

Is there a way we can get more information to isolate a source of the issue?

[JimBobSquarePants]

We need someone to raise an issue upstream here for us to track. We can't fix issues with the AOT compiler.

[Sergio0694]

Is there a way we can get more information to isolate a source of the issue?

Whoops, missed that, sorry!
Yeah we can create a .NET Native repro to send to the team (instructions here), that worked for me in the past 😄

[JimBobSquarePants]

Thanks @Sergio0694 !!

[Sergio0694]

Of course! Let me know if you need help with that! 😊

[JimBobSquarePants]

I'll need you to take point on this if you can please. I have no idea what I'm doing.

[Sergio0694]

@JimBobSquarePants Alright, made the .NET Native repro, would you like me to DM you the file so you can send that yourself or do you want me to send an email to the .NET Native support team with you in cc.? In that case DM me your email address 😄

EDIT: also I forgot, I tried the workaround that Matthew suggested, but without the old SixLabors.Core.dll, and it works!
As in, adding this to the .rd.xml file fixes the Release ARM build:

<Assembly Name="SixLabors.ImageSharp" DoNotOptimize="true" DoNotInline="true" />

[JimBobSquarePants]

I wouldn't consider that a reasonable workaround as people want the optimization. I had to do the same when debugging on the PI and it felt super hacky.

I thought we would be simply raising an issue on a repo somewhere not emailing people no?

[Sergio0694]

Ah yeah absolutely, wasn't suggesting that as a solution, just as a workaround to maybe suggest to users that absolutely need their app using ImageSharp to also work on ARM. In my case for instance, I just dropped that target and only build x86, x64 and ARM64.

I thought we would be simply raising an issue on a repo somewhere not emailing people no?

Yeah no, been there and spoke with multiple engineers in multiple (closed) issues, the only official way to get support for .NET Native and specifically to report bugs is to make a repro and then just send them an email at that support address 😄

[JimBobSquarePants]

I dunno about that now. I would raise the issue in the runtime repo and see what happens.

https://github.com/dotnet/runtime/issues?q=uwp+label%3Aarea-UWP

[Sergio0694]

I mean, you're absolutely free to also open an issue there, but from experience I've had working through a number of .NET Native issues over the years I would tell you that's probably not where you will get support. Take a look at this issue which is the one I opened for a .NET Native bug I stumbled upon last month. You can see the conversation with Michal I had there, which then redirected me towards the email address I mentioned before, and that's where we spoke with him and other .NET Native engineers to actually get support or workarounds for that particular issue.

In particular, quoting directly from Michal:

Email and developer community are the only channels that work.

If you do want to log an issue somewhere that is also public, you can do so here.

And I mean, I can understand why that's the case here, with .NET Native itself not being open source and being a pretty different thing compared to just CoreCLR in general, and handled by different teams as well 🤔

[JimBobSquarePants]

Well that sucks big time; they need a policy change.

Please raise a duplicate of any emails on the public channel then and cc me on the email. Thanks mate, appreciate it! 👍

[Sergio0694]

Yeah the current support policy is not ideal, especially because it can be somewhat confusing/disorienting to either less experienced UWP devs having issues with UWP for the first time, or for devs that simply are not familiar with UWP. Also of course, not having a public, easily accessible issue tracking issue like GitHub means it's not possible to look back on past issues either 😕

Please raise a duplicate of any emails on the public channel then and cc me on the email. Thanks mate, appreciate it! 👍

Of course, happy to help! I still need you to DM me your email address though if you want me to cc. you though 🤣