Partager via

Prise en main de .NET Native

  • Article

Que vous écriviez une nouvelle application UWP ou que vous migrez une application Windows 8.x existante (précédemment appelée application Microsoft Store), vous pouvez suivre le même ensemble de procédures. Pour créer une application .NET Native, procédez comme suit :

  1. Développez une application plateforme Windows universelle (UWP) et testez les builds de débogage de votre application pour vous assurer qu’elle fonctionne correctement.

  2. Gérez l'utilisation de réflexion et de sérialisation supplémentaire.

  3. Déployez et testez les builds de mise en production de votre application.

  4. Résolvez manuellement les métadonnées manquantes et répétez l’étape 3 jusqu’à ce que tous les problèmes soient résolus.

Remarque

Si vous migrez une application Windows 8.x existante vers .NET Native, veillez à passer en revue Migration de votre application Windows 8.x vers .NET Native.

Étape 1 : développer et tester les versions Debug de votre application UWP

Que vous développiez une nouvelle application ou que vous migriez une application existante, vous devez suivre la même procédure que pour n'importe quelle application Windows.

  1. Créez un nouveau projet UWP dans Visual Studio à l’aide du modèle d’application Windows universelle pour Visual C# ou Visual Basic. Par défaut, toutes les applications UWP ciblent CoreCLR et leurs versions de mise en production sont compilées à l’aide de la chaîne de l’outil .NET Native.

  2. Notez qu’il existe certains problèmes de compatibilité connus entre la compilation des projets d’application UWP avec la chaîne de l’outil .NET Native et sans elle. Pour plus d'informations, consultez le guide de migration .

Vous pouvez maintenant écrire du code C# ou Visual Basic sur la surface d’exposition .NET Native qui s’exécute sur le système local (ou dans le simulateur).

Important

Quand vous développez votre application, notez toute utilisation de la sérialisation ou de la réflexion dans votre code.

Par défaut, les builds de débogage sont compilées par JIT pour activer un déploiement F5 rapide, tandis que les builds de mise en production sont compilées à l’aide de la technologie de pré-compilation .NET Native. Cela signifie que vous devez générer et tester les versions Debug de votre application pour vous assurer qu’elles fonctionnent normalement avant de les compiler avec la chaîne de l’outil .NET Native.

Étape 2 : gérer l'utilisation d'une réflexion et d'une sérialisation supplémentaires

Un fichier de directives runtime, Default.rd.xml, est automatiquement ajouté à votre projet au moment de sa création. Si vous développez en C#, il se trouve dans le dossier Propriétés de votre projet. Si vous développez en Visual Basic, il se trouve dans le dossier Mon projet de votre projet.

Remarque

Pour une vue d'ensemble du processus de compilation .NET Native apportant des informations générales sur la nécessité d'un fichier de directives de runtime, voir .NET Native et compilation.

Le fichier de directives runtime permet de définir les métadonnées dont a besoin votre application au moment de l'exécution. Dans certains cas, la version par défaut du fichier peut convenir. Toutefois, un code qui s’appuie sur la sérialisation ou la réflexion peut nécessiter des entrées supplémentaires dans le fichier de directives runtime.

Sérialisation

Il existe deux catégories de sérialiseurs, et les deux peuvent nécessiter des entrées supplémentaires dans le fichier de directives runtime :

  • Sérialiseurs non basés sur la réflexion. Les sérialiseurs qui se trouvent dans la bibliothèque de classes .NET Framework, tels que les classes DataContractSerializer, DataContractJsonSerializer, and XmlSerializer , ne reposent pas sur la réflexion. Toutefois, ils nécessitent que du code soit généré en fonction de l'objet à sérialiser ou à désérialiser. Pour plus d’informations, consultez la section « Sérialiseurs Microsoft » dans Serialization and Metadata.

  • Sérialiseurs tiers. Les bibliothèques de sérialisation tierces, dont la plus courante est le sérialiseur JSON Newtonsoft, sont généralement basées sur la réflexion et nécessitent des entrées dans le fichier *.rd.xml pour prendre en charge la sérialisation et la désérialisation des objets. Pour plus d’informations, consultez la section « Sérialiseurs tiers » dans Serialization and Metadata.

Méthodes basées sur la réflexion

Dans certains cas, l'utilisation de la réflexion dans le code n'est pas évidente. Certains modèles de programmation ou API courants ne sont pas considérés comme faisant partie de l'API de réflexion, mais s'appuient sur la réflexion pour s'exécuter correctement. Cela comprend les méthodes d'instanciation de type et de construction de méthode suivantes :

Pour plus d'informations, consultez APIs That Rely on Reflection.

Remarque

Les noms de types utilisés dans les fichiers de directives runtime doivent être qualifiés complets. Par exemple, le fichier doit spécifier « System.String » au lieu de « String ».

Étape 3 : déployer et tester les versions de mise en production de votre application

Une fois que vous avez mis à jour le fichier de directives runtime, vous pouvez reconstruire et déployer des builds de mise en production de votre application. Les fichiers binaires .NET Native sont placés dans le sous-répertoire ILC.out du répertoire spécifié dans la zone de texte Chemin de sortie de build de la boîte de dialogue Propriétés du projet, onglet Compilation. Les fichiers binaires qui ne se trouvent pas dans ce dossier n’ont pas été compilés avec .NET Native. Testez votre application minutieusement et testez tous les scénarios, y compris les scénarios d’erreur, sur chacune de ses plateformes cibles.

Si votre application ne fonctionne pas correctement (en particulier dans les cas où elle lève missingMetadataException ou MissingInteropDataException au moment de l’exécution), suivez les instructions de la section suivante, étape 4 : Résoudre manuellement les métadonnées manquantes. L'activation des exceptions de première chance peut vous aider à trouver ces bogues.

Lorsque vous avez testé et débogué les builds de débogage de votre application et que vous êtes certain que vous avez éliminé les exceptions MissingMetadataException et MissingInteropDataException, vous devez tester votre application en tant qu’application .NET Native optimisée. Pour ce faire, dans la configuration du projet actif, remplacez Débogage par Version finale.

Étape 4 : résoudre manuellement les métadonnées manquantes

L’échec le plus courant que vous rencontrerez avec .NET Native que vous ne rencontrez pas sur le bureau est une exception MissingMetadataException, MissingInteropDataException ou MissingRuntimeArtifactException. Dans certains cas, l'absence de métadonnées peut se manifester par un comportement imprévisible ou même se traduire par des erreurs d'application. Cette section explique comment vous pouvez déboguer et résoudre ces exceptions en ajoutant des directives au fichier de directives runtime. Pour plus d’informations sur le format des directives runtime, consultez le Guide de référence du fichier de configuration des directives runtime (rd.xml). Une fois que vous avez ajouté des directives d’exécution, vous devez déployer et tester à nouveau votre application et résoudre les nouvelles exceptions MissingMetadataException, MissingInteropDataException et MissingRuntimeArtifactException jusqu’à ce que vous rencontriez plus d’exceptions.

Conseil

Spécifiez les directives runtime à un niveau élevé pour que votre application tolère les modifications de code. Nous vous recommandons d'ajouter les directives runtime aux niveaux de l'espace de noms et du type, plutôt qu'au niveau du membre. Notez qu'un compromis peut s'avérer nécessaire entre la résilience et les fichiers binaires volumineux dont la compilation prend plus de temps.

Quand vous traitez une exception liée à des métadonnées manquantes, prenez en compte les points suivants :

  • Qu'est-ce que l'application essayait de faire avant l'exception ?

    • Par exemple, était-elle en train de lier, de sérialiser ou de désérialiser des données ou d'utiliser directement l'API de réflexion ?

  • S'agit-il d'un cas isolé, ou pensez-vous que vous rencontrerez le même problème pour d'autres types ?

    • Par exemple, une exception MissingMetadataException est levée lors de la sérialisation d’un type dans le modèle objet de l’application. Si vous connaissez d'autres types à sérialiser, vous pouvez ajouter des directives runtime pour ces types (ou pour leurs espaces de noms conteneurs, suivant la façon dont le code est organisé) en même temps.

  • Pouvez-vous réécrire le code afin qu’il n’utilise pas la réflexion ?

    • Par exemple, le code utilise-t-il le mot clé dynamic quand vous connaissez le type attendu ?

    • Le code appelle-t-il une méthode basée sur la réflexion quand une meilleure solution est disponible ?

Remarque

Pour plus d’informations sur la gestion des problèmes liés à la réflexion et à la disponibilité des métadonnées dans les applications de bureau et .NET Native, consultez les API qui reposent sur la réflexion.

Pour obtenir des exemples spécifiques de gestion des exceptions et d'autres problèmes qui se produisent quand vous testez votre application, consultez :

Voir aussi