Éviter les bogues .NET natifs

Question

J'ai passé l'année dernière (à temps partiel) à migrer mon application Windows 8.1 existante (et réussie) vers Windows 10 UWP. Maintenant, juste avant de le relâcher au magasin, j'ai testé l'application dans le mode de construction "Release" (qui déclenche .NET Native). Tout semblait fonctionner jusqu'à ce que, par hasard, je remarque un bug subtil mais sérieux (car compromettant les données). Il m'a fallu deux jours pour le réduire à ces trois lignes de 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."; 
} 

En mode débogage, le clonage du tableau 2D signifie modification d'un élément de tableau ne modifie pas l'autre tableau. En mode Release, la modification d'un tableau modifie également l'autre. (J'utilise le dernier VS 2017.)

Maintenant, j'ai réalisé que l'utilisation de .NET Native 1.6 (qui n'est pas la valeur par défaut dans VS 2017), résout ce problème particulier. Mais j'ai perdu la foi en .NET Native. Combien de bogues sont toujours introduits par .NET Native dans mon application? Mon application Windows 8.1 s'exécute rapidement et en douceur sans .NET Native. Alors pourquoi devrais-je utiliser .NET Native qui semble être plein de bugs? (J'ai appris beaucoup de bugs .NET natifs ces deux derniers jours.)

Récemment, le projet "UWP Desktop Bridge" a permis de publier des applications de bureau traditionnelles sur l'App Store (ils n'ont pas besoin d'être utilisés). NET Native). Alors pourquoi dois-je utiliser .NET Native?

Existe-t-il un moyen d'ignorer totalement .NET Native? Sinon, puis-je configurer le compilateur .NET natif pour qu'il ne se comporte pas de manière aussi destructive?

Answer 1

Cela pourrait être un bug sur la chaîne d'outils natif .NET ...

De mes tests, Array.Copy fonctionne comme prévu:

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 natif dev ici - désolé pour la peine que vous J'ai rencontré. Comme vous l'avez dit, le problème que vous avez rencontré avec Array.Clone has been fixed (par inadvertance - comme un effet secondaire d'un correctif différent) avec .NET Native 1.6 et nous serons heureux de résoudre tous les autres problèmes que vous avez rencontrés. Pour apporter .NET Native, nous avons dû réécrire à peu près tous les CLR (avec plus de 15 ans de corrections de bogues). Nous sommes à l'étape v1 et vous êtes tout simplement plus susceptible de rencontrer un bug dans .NET Native que dans le CLR. La plupart des gens ne rencontrent pas de bugs sur les deux plates-formes. Grâce à l'utilisation de .NET Native, les utilisateurs de Windows peuvent bénéficier d'améliorations de 30 à 60% du temps de démarrage dans toutes les applications UWP (par rapport à CLR). Cela n'a peut-être pas beaucoup d'importance sur votre machine de développement, mais cela compte beaucoup pour l'expérience utilisateur sur les tablettes bon marché. Actuellement, nous n'offrons pas l'option .NET Native désactivée.

J'ai déposé an issue pour améliorer notre couverture de test pour Array.Clone afin que cela ne se reproduise plus (surtout parce que nous ne savions même pas qu'il était cassé).

Si vous frappez un problème à l'avenir:

• Vous pouvez contacter l'équipe de développement directement à dotnetnative (chez Microsoft com)
• Vous pouvez soumettre un correctif. .NET Native pour les applications UWP chevauche grandement avec CoreRT repo sur GitHub et une grande partie du code est partagée.