Common Intermediate Language

Dans l'environnement de programmation Microsoft, le Common Intermediate Language (CIL) est le langage de programmation de plus bas niveau qui peut être lu par un humain. Le code de plus haut niveau dans l'environnement .NET est compilé en code CIL qui est assemblé dans un code dit bytecode. CIL est un code assembleur orienté objet et pile. Il est exécuté par une machine virtuelle.

Le CIL était initialement connu sous le nom de Microsoft Intermediate Language ou MSIL durant les bêtas du langage .NET. Après la standardisation du C# et de la CLI, le bytecode fut officiellement référencé sous le nom de CIL. Les utilisateurs précoces de la technologie continuent néanmoins à se référer au terme MSIL.

Compilateur JIT/NGEN

Durant la compilation .NET, le code source est transformé en un code CIL portable, indépendant de la plateforme et du processeur, et appelé bytecode.

Ce bytecode est compilé par la CLR/DLR en temps réel pour obtenir un code immédiatement exécutable par le processeur. Durant cette compilation, le compilateur (JIT) effectue un grand nombre de tâches pour éviter des accès illégaux à la mémoire :

• optimisation spécifique à la plateforme
• sécurisation des types
• vérification des assembly

Cette compilation peut aussi être réalisée avec un générateur natif d'image (NGEN). Cet outil a pour but de supprimer le temps d'attente dû à la compilation qui a lieu au niveau des CLR et DLR. Attention, l'image binaire native est placée dans le cache des 'assemblies' mais nécessite pour s'exécuter le fichier d'origine (certaines informations ne sont pas recopiées dans l'image)[1].

.NET metadata

.NET enregistre les informations concernant les classes compilées dans un fichier de nom metadata. Ces données agissent comme la bibliothèque Component Object Model, et permettent aux applications compatibles de découvrir les interfaces, les classes, les types, et les méthodes présentes dans le code assembleur. Le processus de lecture de ces données est appelé réflexion. Ces données peuvent être lues en utilisant l'outil ILDASM fourni avec le SDK .NET Framework.

Toute la CIL est autodescriptive, grâce aux Métadonnées .NET. La CLR vérifie les métadonnées pour s'assurer que la bonne méthode est appelée. Les métadonnées sont généralement générées par les compilateurs des langages, mais les développeurs peuvent aussi créer leurs propres métadonnées via l'utilisation d'attributs personnalisés. Les métadonnées contiennent aussi des informations à propos des assemblages et sont aussi utilisées pour implémenter la capacité de réflexion du .NET Framework.

.NET assemblies

Le code CIL est stocké dans les assemblages .NET (ou assemblies).

L'assemblage est le bloc de structuration fondamental des applications .NET. Un assemblage regroupe l'ensemble des éléments nécessaires au bon fonctionnement d'une application (ou partie d'une application) : exécutables, métadonnées, autorisations, ressources (images...), etc. Le concept d'assemblage a été introduit pour résoudre les problèmes d'installation, d'évolution de version, d'internationalisation, de contexte d'exécution, de conflits de DLL... À ce titre, c'est une unité de déploiement indivisible.

Les assemblages sont constitués d´un ou plusieurs fichiers, dont l'un doit contenir un document XML appelé manifeste. Le manifeste[2] contient :

• la liste de l'ensemble des fichiers utilisés (exécutables, DLL, données, images, ressources)
• les métadonnées,
• la liste des autres assemblages utilisés par l'application
• l'ensemble des informations liées aux autorisations et à la sécurité de l'assemblage.

Les assemblages .NET sont enregistrés au format exécutable portable (PE) courant sur la plate-forme Windows pour tous les fichiers DLL ou EXE. Le nom complet d'un assemblage (à ne pas confondre avec le nom du fichier sur le disque) contient son nom simple, son numéro de version, sa culture et sa clé publique. La clé publique est unique et est générée à partir du hachage de l'assemblage après sa compilation. En conséquence, deux assemblages avec la même clé publique sont garantis d'être identiques. Une clé privée peut aussi être spécifiée ; elle est uniquement connue du créateur de l'assemblage et peut être utilisée pour le nommage fort de celui-ci. Cela garantit que l'assemblage est du même auteur lors de la compilation d'une nouvelle version.

Le code CIL d'un assemblage .NET existe sous deux formes : exécutables (process assemblies) et DLL (library assemblies). Lors de la compilation, le choix du format final du fichier contenant le code source ne dépend pas de l'extension du fichier mais d'une information stockée dans un fichier PE. Ce fait explique que, dans un même répertoire, deux fichiers de même nom mais avec des extensions différentes ne peuvent par défaut exister. Ce problème a été résolu par l'utilisation d'une clé publique/privée pour signer une DLL ou un exécutable et par l'introduction par .NET du GAC.

Notes et références

1. http://msdn.microsoft.com/fr-fr/library/6t9t5wcf(VS.80).aspx
2. Assembly Manifest

Voir aussi

• IL2CPU