Avoid .NET Native bugs

Question

I spent the last year (part time) to migrate my existing (and successful) Windows 8.1 app to Windows 10 UWP. Now, just before releasing it to the store, I tested the app in the "Release" build mode (which triggers .NET Native). Everything seemed to work until I - by chance - noted a subtle but serious (because data-compromising) bug. It took me two days to reduce it to these three lines of code:

var array1 = new int[1, 1];
var array2 = (int[,])array1.Clone();
array2[0, 0] = 666;

if (array1[0, 0] != array2[0, 0]) {
    ApplicationView.GetForCurrentView().Title = "OK.";
} else {
    ApplicationView.GetForCurrentView().Title = "Bug.";
}

In Debug mode, cloning the 2D array means modifying one array item does not affect the other array. In Release mode, modifying one array changes the other, too. (I am using the latest VS 2017.)

Now, I realized that using .NET Native 1.6 (which is not the default in VS 2017), solves this particular issue.

But I lost the faith in .NET Native. How many bugs are still introduced by .NET Native into my app? My Windows 8.1 app runs fast and smoothly without .NET Native. So why should I have to use .NET Native which seems to be full of bugs? (I got to know a lot of .NET Native bugs in the last two days.)

Recently, project "UWP Desktop Bridge" has allowed to publish traditional desktop apps to the App Store (they do not have to use .NET Native). So why do I have to use .NET Native?

Is there a way to skip .NET Native totally? If not, can I configure the .NET Native compiler to behave not so destructive?

Answer 1

That might be a bug on the .NET Native tool chain...

From my tests, Array.Copy works as expected:

var array1 = new int[1, 1];
var array2 = new int[1, 1];
Array.Copy(array1, array2, array1.Length);
array2[0, 0] = 666;

if (array1[0, 0] != array2[0, 0])
{
    ApplicationView.GetForCurrentView().Title = "OK.";
}
else
{
    ApplicationView.GetForCurrentView().Title = "Bug.";
}

Answer 2

.NET Native dev here - sorry for the trouble you've encountered. As you said, the problem you hit with Array.Clone has been fixed (inadvertently - as a side effect of a different fix) with .NET Native 1.6 and we will be happy to fix any other issues you've encountered.

In order to bring .NET Native, we had to pretty much rewrite all of the CLR (with 15+ years of bug fixes in it). We are in the v1 stage and you're simply more likely to hit a bug in .NET Native than you are in the CLR. Most people don't encounter any bugs on either platform though. As a result of using .NET Native, Windows users can enjoy 30-60% improvements in startup time in all UWP apps (compared to CLR). It might not matter a lot on your development machine, but it matters a lot for the user experience on cheap tablets. We don't currently offer turning .NET Native off as an option.

I filed an issue to improve our test coverage for Array.Clone so that this doesn't happen again (especially because we didn't even know it was broken).

If you hit an issue in the future:

• You can contact the dev team directly at dotnetnative (at microsoft com)
• You can submit a fix. .NET Native for UWP apps overlaps greatly with CoreRT repo on GitHub and a lot of the code is shared.