You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
ImageSharp-rc1 fails to build on UWP Release ARM #1204
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
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-South
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:
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.
@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:
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 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 😄
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 🤔
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 🤣
Activity
[-]ImageSharp.Drawing-008 fails to build on UWP Release ARM[/-][+]ImageSharp-rc1 fails to build on UWP Release ARM[/+]MattWhilden commentedon May 26, 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.
MattWhilden commentedon May 26, 2020
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:
Sergio0694 commentedon May 26, 2020
Hey @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:In particular, that warning sounds interesting:
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 commentedon May 26, 2020
Ah, maybe I misremembered which binaries get pulled in. Might be a completely spurious. :-D
JimBobSquarePants commentedon May 27, 2020
@Sergio0694 That binary shouldn't exist now!
JimBobSquarePants commentedon Aug 26, 2020
Is there a way we can get more information to isolate a source of the issue?
JimBobSquarePants commentedon Oct 13, 2020
We need someone to raise an issue upstream here for us to track. We can't fix issues with the AOT compiler.
Sergio0694 commentedon Oct 13, 2020
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 commentedon Oct 13, 2020
Thanks @Sergio0694 !!
Sergio0694 commentedon Oct 13, 2020
Of course! Let me know if you need help with that! 😊
JimBobSquarePants commentedon Oct 13, 2020
I'll need you to take point on this if you can please. I have no idea what I'm doing.
Sergio0694 commentedon Oct 13, 2020
@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:JimBobSquarePants commentedon Oct 13, 2020
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 commentedon Oct 13, 2020
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.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 commentedon Oct 13, 2020
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 commentedon Oct 13, 2020
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:
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 commentedon Oct 13, 2020
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 commentedon Oct 14, 2020
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 😕
Of course, happy to help! I still need you to DM me your email address though if you want me to cc. you though 🤣
Disable NetNative optimization on UWP. Fix #1204
Disable NetNative optimization on UWP. Fix #1204