Repository navigation
How can I build a release version with ImageSharp #198
Description
Hi,
I use ImageSharp alpha7-00031 and ImageSharp.Drawing alpha7-00045 in my own UWP project. When I build it in Debug-Mode all is fine.
When I build it in Release-Mode I get the following Error:
1>C:\Program Files (x86)\MSBuild\Microsoft.NetNative\x86\ilc\IlcInternals.targets(936,5): error : Internal compiler error: The object reference was not set to an object instance.
I am using Microsoft Visual Studio Enterprise 2015, Microsoft.NETCore.UniversalWindowsPlatform 5.2.2 and NETStandard.Library 1.6.1
Activity
vpenades commentedon Apr 28, 2017
Yes, it seems there's an issue with the Net.Native Compiler used by UWP in VS 2015.
The conditions to produce the exception (most of the time a null exception but not always) are these:
If all these conditions meet, sometimes you get weird exceptions.
I first found this bug two months ago in our own project and drove me crazy, finally I reported it to Microsoft and confirmed it was a bug in the compiler, which, apparently, it's been fixed on Visual Studio 2017.
Solutions:
Btw, when I reported this bug to Microsoft, I also told them to keep an eye on ImageSharp, since there where high chances ImageSharp would be affected by this issue too... I recall Matthew from MS popped up here a while ago...
JimBobSquarePants commentedon Apr 28, 2017
Hi @Sniger87
The readme specifically states VS2017 as a minimum requirement so you really have to use that. As @vpenades correctly states (thanks for that btw 👍 ) don't use 32bit. MS don't support SIMD yet on 32bit platforms but will do when they switch out the jitter as part of the NetStandard 2.0.0 release in a couple of months. So until then performance will be pretty poor.
Hopefully all this is possible for you and makes sense.
Cheers
James
Sniger87 commentedon May 2, 2017
Hi @JimBobSquarePants and @vpenades ,
Thanks for the quick help!
Cheers
Sniger
JimBobSquarePants commentedon May 2, 2017
No worries 😄
mikegoatly commentedon Jan 16, 2018
@vpenades apologies for adding to a closed issue, but was the bug you raised with Microsoft publicly trackable somewhere? As soon as I add ImageSharp code to my UWP project, I'm still getting this null ref exception when compiling to native x86. I'm using the latest VS2017 (15.5.3) and I've even tried the latest preview 15.6.0 Preview 2 with the same results.
Given that targeting all architectures for a UWP build is recommended best practice, it's hard to see how ImageSharp can be effectively used in a UWP app at the moment.
vpenades commentedon Jan 16, 2018
@mikegoatly As far as I know, no, I reported it through an unofficial channel, and I was told the issue was already solved in the first version of Vs2017... and that was the case since the moment we moved to VS2017 the problem disappeared.
To correctly identify the issue, be sure that you get different results when compiling in 32 and 64 bits... if it fails on both then it's another kind of bug than the reported here.
If it only fails in 32bit and works fine in 64bit, my suggestion is to report it to Microsoft, and carry on developing in 64bit only until they get the fix. This is what we did at the time.
mikegoatly commentedon Jan 16, 2018
@vpenades Thanks- yeah, I've just done some more investigation and it looks like the problem only manifests itself with the latest beta version of the ImageSharp package.
A simple repro is:
Using ImageSharp 0.9.0 or just compiling x64/ARM does not cause the error to occur.
I'll get an issue raised with Microsoft tonight.
vpenades commentedon Jan 16, 2018
@mikegoatly notice that this issue is deeply related to this one: #146
If you read it, Matt Whilden suggest to write directly to dotnetnative@microsoft.com , dunno if it's still the right channel to solve this.
Also I would suggest to create a repo with a small project that reproduces the issue so others can check if it can be reproduced.
mikegoatly commentedon Jan 16, 2018
Cool, thanks for the pointer @vpenades - I'll do that. I'll also have a play with different versions of the
Microsoft.NETCore.UniversalWindowApplicationpackage to see if that provides any more clues.mikegoatly commentedon Jan 16, 2018
Repro created and email sent. I'll update here if I hear anything.
antonfirsov commentedon Jan 16, 2018
If this issue is actually related to multithreading, I wonder if this workaround helps:
mikegoatly commentedon Jan 19, 2018
Ok, a quick update on this: It's a new compiler issue - the team at Microsoft are hoping to get it fixed for the next release.
vpenades commentedon Jan 19, 2018
@mikegoatly thanks, did you got some insight of the compiler issue?
It's funny to see how imagesharp is prone to hit msbuild compiler bugs... 😂
JimBobSquarePants commentedon Jan 19, 2018
It's cos we're so cutting edge 😄
mikegoatly commentedon Jan 20, 2018
The only detail was that it was likely something to do with the use of Memory and Span, so yeah I guess it's the cutting edge element!