Partager via

.NET Native et compilation

Les applications de bureau Windows qui ciblent .NET Framework sont écrites dans un langage de programmation particulier et compilées en langage intermédiaire (IL). Au moment de l’exécution, un compilateur juste-à-temps (JIT) est chargé de compiler l'IL en code natif pour la machine locale juste avant l’exécution initiale d’une méthode. En revanche, la chaîne d’outils .NET Native convertit le code source en code natif au moment de la compilation. Cet article compare .NET Native à d’autres technologies de compilation disponibles pour les applications .NET Framework, et fournit également une vue d’ensemble pratique de la façon dont .NET Native produit du code natif qui peut vous aider à comprendre pourquoi les exceptions qui se produisent dans le code compilé avec .NET Native ne se produisent pas dans le code compilé JIT.

Génération de fichiers binaires natifs

Une application qui cible .NET Framework et qui n’est pas compilée à l’aide de la chaîne d’outils .NET Native se compose de l’assembly d’application, qui inclut les éléments suivants :

  • métadonnées qui décrit l’assembly, ses dépendances, les types qu’il contient et leurs membres. Les métadonnées sont utilisées pour l’accès à la réflexion et à liaison tardive, et dans certains cas par le compilateur et les outils de génération.

  • Code d’implémentation. Cela se compose d’opcodes de langage intermédiaire (IL). Au moment de l’exécution, le compilateur juste-à-temps (JIT) le traduit en code natif pour la plateforme cible.

En plus de l’assembly d’application principal, une application nécessite que les éléments suivants soient présents :

  • Toutes les bibliothèques de classes ou assemblages tiers supplémentaires requis par votre application. Ces assemblies incluent également les métadonnées qui décrivent l’assembly, ses types et leurs membres, ainsi que l'IL qui implémente tous les membres de type.

  • Bibliothèque de classes .NET Framework. Il s’agit d’une collection d’assemblys installés sur le système local avec l’installation de .NET Framework. Les assemblys inclus dans la bibliothèque de classes .NET Framework incluent un ensemble complet de métadonnées et de code d’implémentation.

  • L'environnement d'exécution pour les langages communs. Il s’agit d’une collection de bibliothèques de liens dynamiques qui assurent des services tels que le chargement d’assembly, la gestion de la mémoire et le nettoyage de mémoire, la gestion des exceptions, la compilation à la demande, le relais à distance et l’interop. Comme la bibliothèque de classes, le runtime est installé sur le système local dans le cadre de l’installation de .NET Framework.

Notez que l’ensemble du Common Language Runtime, ainsi que les métadonnées et l’il pour tous les types dans les assemblys spécifiques à l’application, les assemblys tiers et les assemblys système doivent être présents pour que l’application s’exécute correctement.

Compilation juste-à-temps

L’entrée de la chaîne d’outils .NET Native est l’application UWP créée par le compilateur C# ou Visual Basic. En d’autres termes, la chaîne d’outils .NET Native commence à s’exécuter lorsque le compilateur de langage a terminé la compilation d’une application UWP.

Conseil / Astuce

Étant donné que l'entrée de .NET Native est le code IL et les métadonnées écrites dans des assemblys managés, vous pouvez toujours effectuer une génération de code personnalisée ou d'autres opérations personnalisées à l'aide d'événements de pré-compilation ou post-compilation, ou en modifiant le fichier projet MSBuild.

Toutefois, les catégories d’outils qui modifient l’il et empêchent ainsi la chaîne d’outils .NET d’analyser l’il d’une application ne sont pas prises en charge. Les obfuscators sont les outils les plus notables de ce type.

Au cours de la conversion d’une application d’il en code natif, la chaîne d’outils .NET Native effectue des opérations comme suit :

  • Pour certains chemins de code, il remplace le code qui s’appuie sur la réflexion et les métadonnées par du code natif statique. Par exemple, si un type valeur ne remplace pas la méthode, le test par défaut pour l’égalité ValueType.Equals utilise la réflexion pour récupérer des FieldInfo objets qui représentent les champs du type valeur, puis compare les valeurs de champ de deux instances. Lors de la compilation vers du code natif, la chaîne d’outils .NET Native remplace le code de réflexion et les métadonnées par une comparaison statique des valeurs de champ.

  • Si possible, il tente d’éliminer toutes les métadonnées.

  • Il inclut uniquement dans les assemblys d’application finals le code d’implémentation qui est réellement appelé par l’application. Cela affecte particulièrement le code dans les bibliothèques tierces et dans la bibliothèque de classes .NET Framework. Par conséquent, une application ne dépend plus des bibliothèques tierces ou de la bibliothèque de classes .NET Framework complète ; Au lieu de cela, le code dans les bibliothèques de classes .NET Framework et tierces est désormais local dans l’application.

  • Il remplace le CLR complet par un environnement d'exécution refactorisé qui contient principalement le ramasse-miettes. Le nouvel environnement d'exécution se trouve dans une bibliothèque nommée mrt100_app.dll qui est local à l'application et ne fait que quelques centaines de kilo-octets. Cela est possible, car la liaison statique élimine le besoin de nombreux services effectués par le Common Language Runtime.

    Remarque

    .NET Native utilise le même garbage collector que le Common Language Runtime standard. Dans le collecteur de déchets .NET Native, la collecte de déchets en arrière-plan est activée par défaut. Pour plus d’informations sur la collecte des déchets, consultez Principes fondamentaux de la collecte des déchets.

Important

.NET Native compile une application entière vers une application native. Il ne vous permet pas de compiler un assembly unique qui contient une bibliothèque de classes en code natif afin qu’elle puisse être appelée indépendamment du code managé.

L’application résultante produite par la chaîne d’outils .NET Native est écrite dans un répertoire nommé ilc.out dans le répertoire Debug ou Release de votre répertoire de projet. Il se compose des fichiers suivants :

  • <appName>.exe, un exécutable stub qui transfère simplement le contrôle à une exportation spéciale de Main dans <appName>.dll.

  • <appName>.dll, une bibliothèque de liens dynamiques Windows qui contient tout votre code d’application, ainsi que du code de la bibliothèque de classes .NET Framework et de toutes les bibliothèques tierces dont vous avez une dépendance. Il contient également du code de prise en charge, tel que le code nécessaire pour interagir avec Windows et sérialiser des objets dans votre application.

  • mrt100_app.dll, un environnement d'exécution refactorisé qui offre des services d'exécution, tels que la collecte des déchets.

Toutes les dépendances sont capturées par le manifeste APPX de l’application. En plus de l’exe, dll et mrt100_app.dlld’application, qui sont regroupés directement dans le package appx, cela inclut deux autres fichiers :

  • msvcr140_app.dll, la bibliothèque C run-time (CRT) utilisée par mrt100_app.dll. Il est inclus par une référence de framework dans le package.

  • mrt100.dll. Cette bibliothèque inclut des fonctions qui peuvent améliorer les performances de mrt100_app.dll, bien que son absence n’empêche pas mrt100_app.dll de fonctionner. Il est chargé à partir du répertoire system32 sur l’ordinateur local, s’il est présent.

Étant donné que la chaîne d’outils .NET Native lie le code d’implémentation à votre application uniquement si elle sait que votre application appelle réellement ce code, les métadonnées ou le code d’implémentation requis dans les scénarios suivants peuvent ne pas être inclus dans votre application :

  • Réflexion.

  • Appel dynamique ou à liaison tardive.

  • Sérialisation et désérialisation.

  • Interopérabilité COM.

Si les métadonnées ou le code d’implémentation nécessaires sont absents lors de l’exécution, le runtime .NET Native lève une exception. Vous pouvez empêcher ces exceptions et vous assurer que la chaîne d’outils .NET Native inclut les métadonnées et le code d’implémentation requis, à l’aide d’un fichier de directives runtime, d’un fichier XML qui désigne les éléments de programme dont les métadonnées ou le code d’implémentation doivent être disponibles au moment de l’exécution et leur assigne une stratégie d’exécution. Voici le fichier de directives runtime par défaut ajouté à un projet UWP compilé par la chaîne d’outils .NET Native :

<Directives xmlns="http://schemas.microsoft.com/netfx/2013/01/metadata">
  <Application>
    <Assembly Name="*Application*" Dynamic="Required All" />
  </Application>
</Directives>

Cela permet à tous les types, ainsi qu’à tous leurs membres, dans toutes les assemblies de votre package d’application, d’utiliser la réflexion et l'appel dynamique. Toutefois, elle n’active pas la réflexion ou l’activation dynamique des types dans les assemblys de bibliothèque de classes .NET Framework. Dans de nombreux cas, cela est suffisant.

Voir aussi