Repository navigation
ImageSharp-rc1 fails to build on UWP Release ARM #1204
Description
Activity
- changed the title
[-]ImageSharp.Drawing-008 fails to build on UWP Release ARM[/-][+]ImageSharp-rc1 fails to build on UWP Release ARM[/+]on May 22, 2020 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.
Reacted by Anton Firszov, Sergio Pedri and James Jackson-SouthOh, 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" />Reacted by yukiokun057Hey @MattWhilden - that's great, thank you for looking into this! 😊
I tried your
.rd.xmlfix 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! 😄
Reacted by Matthew WhildenAh, maybe I misremembered which binaries get pulled in. Might be a completely spurious. :-D
SixLabors.Core.dll
@Sergio0694 That binary shouldn't exist now!
Reacted by Anton Firszov and Matthew WhildenIs there a way we can get more information to isolate a source of the issue?
We need someone to raise an issue upstream here for us to track. We can't fix issues with the AOT compiler.
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 😄Reacted by James Jackson-SouthThanks @Sergio0694 !!
Of course! Let me know if you need help with that! 😊
I'll need you to take point on this if you can please. I have no idea what I'm doing.
Reacted by Sergio PedriReacted by Sergio Pedri@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.xmlfile fixes the Release ARM build:<Assembly Name="SixLabors.ImageSharp" DoNotOptimize="true" DoNotInline="true" />
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?
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
ImageSharpto 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 😄
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
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 🤔
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! 👍
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 🤣
Reacted by James Jackson-South- added a commit that references this issue
on Oct 16, 2020 - added a commit that references this issue
on Mar 13, 2021
Possibly related to #987 and #828
Prerequisites
DEBUGandRELEASEmodeDescription
Building a UWP app in Release ARM fails to build when using
ImageSharp-rc1, and the UWP compiler version6.2.10(latest). Downgrading to-beta007works for now.Here's the issue I'm getting:
Building Release x86, x64 and ARM64 works fine 🤷♂️
Pinging @MattWhilden for his infinite .NET Native knowledge and wisdom 🧙♂️
Steps to Reproduce
19041target,17763minimum)ImageSharp-rc1packageSystem Configuration
ImageSharp-rc1.NETCore.UniversalWindowsPlatform 6.2.1019041.264