AccueilđŸ‡«đŸ‡·Chercher

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

Voir aussi

Cet article est issu de wikipedia. Text licence: CC BY-SA 4.0, Des conditions supplĂ©mentaires peuvent s’appliquer aux fichiers multimĂ©dias.