Partager via

Bien démarrer avec .NET Native

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 de plateforme Windows universelle (UWP), et testez les builds de débogage de votre application pour vous assurer qu'elle fonctionne correctement.

  2. Gérer l'utilisation supplémentaire depour la réflexion et la sérialisation.

  3. Déployer et tester les builds de mise en production de votre application.

  4. résoudre manuellement les métadonnées manquanteset répéter é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 de débogage de votre application Windows universelle (UWP)

Que vous développiez une nouvelle application ou que vous migrez une application existante, vous suivez le même processus que pour n’importe quelle application Windows.

  1. Créez un 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 builds de mise en production sont compilées à l’aide de la chaîne d’outils .NET Native.

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

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

Important

Lorsque 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 builds de débogage de votre application pour vous assurer qu’elles fonctionnent normalement avant de les compiler avec la chaîne d’outils .NET Native.

Étape 2 : Gérer l’utilisation supplémentaire de la réflexion et de la sérialisation

Un fichier de directives runtime, Default.rd.xml, est automatiquement ajouté à votre projet lorsque vous le créez. 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, celui-ci se trouve dans le dossier Mon projet de votre projet.

Remarque

Pour obtenir une vue d’ensemble du processus de compilation .NET Native qui fournit un arrière-plan sur la raison pour laquelle un fichier de directives runtime est nécessaire, consultez .NET Native et compilation.

Le fichier de directives runtime est utilisé pour définir les métadonnées dont votre application a besoin au moment de l’exécution. Dans certains cas, la version par défaut du fichier peut être adéquate. Toutefois, certains codes qui s’appuient sur la sérialisation ou la réflexion peuvent 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 fondés sur la réflexion. Les sérialiseurs trouvés dans la bibliothèque de classes .NET Framework, tels que les classes DataContractSerializer, DataContractJsonSerializeret XmlSerializer, ne s’appuient pas sur la réflexion. Toutefois, ils nécessitent que le 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 la sérialisation et les métadonnées.

  • Sérialiseurs tiers. Les bibliothèques de sérialisation tierces, les plus courantes étant 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 sérialisation et métadonnées.

Méthodes qui s'appuient sur la réflexion

Dans certains cas, l’utilisation de la réflexion dans le code n’est pas évidente. Certaines API ou modèles de programmation 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 inclut les méthodes d’instanciation de type et de construction de méthode suivantes :

Pour plus d’informations, consultez API qui reposent sur la réflexion.

Remarque

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

Étape 3 : Déployer et tester les builds 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 du chemin de sortie Build output path de la boîte de dialogue "Propriétés" du projet, onglet Compiler. Les fichiers binaires qui ne figurent pas dans ce dossier n'ont pas été compilés avec .NET Native. Testez soigneusement votre application et testez tous les scénarios, y compris les scénarios d’échec, 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 exceptions 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 MissingMetadataException et MissingInteropDataException exceptions, vous devez tester votre application en tant qu’application .NET Native optimisée. Pour ce faire, modifiez la configuration de votre projet actif de de débogage en version de production.

É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 poste de travail, est une exception de runtime MissingMetadataException, MissingInteropDataException, ou MissingRuntimeArtifactException. Dans certains cas, l’absence de métadonnées peut se manifester en comportement imprévisible ou même en échecs d’application. Cette section explique comment 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 d’exécution, consultez Directives d'exécution (rd.xml) Informations de référence sur le fichier de configuration. 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 MissingMetadataException, MissingInteropDataException, et MissingRuntimeArtifactException exceptions jusqu’à ce que vous ne rencontriez plus d’exceptions.

Conseil / Astuce

Spécifiez les directives d’exécution à un niveau élevé pour permettre à votre application d’être résiliente aux modifications de code. Nous vous recommandons d’ajouter des directives d’exécution aux niveaux d’espace de noms et de type plutôt qu’au niveau membre. Notez qu’il peut y avoir un compromis entre la résilience et les fichiers binaires plus volumineux avec des temps de compilation plus longs.

Lorsque vous traitez une exception de métadonnées manquante, tenez compte des problèmes suivants :

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

    • S'agissait-il, par exemple, de la liaison de données, de la sérialisation ou de la désérialisation des données, ou de l'utilisation directe de 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 qui seront sérialisés, vous pouvez ajouter des directives d’exécution pour ces types (ou pour leurs espaces de noms contenants, selon 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 lorsque vous connaissez le type à attendre ?

    • Le code appelle-t-il une méthode qui dépend de la réflexion quand une meilleure alternative 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 lors du test de votre application, consultez :

Voir aussi

  • Last updated on