Lorsque vous avez plusieurs langues, comment fonctionnent-elles toutes ensemble pour s’exécuter ? La plupart des autres langages de programmation n’utilisent pas le format Portable Executable (PE) pour leurs exécutables. L’environnement .NET apporte quelque chose de nouveau : une approche logique des exécutables nommés assemblys. Le CLR gère l’intégralité de l’exécution d’un assembly. L’assembly possède une collection de des fichiers appelés assemblys statiques, que le CLR utilise. Les assemblys statiques peuvent être des ressources utilisées par l’assembly, telles que des fichiers image ou des fichiers texte que l’application utilisera. Le code réel qui s’exécute se trouve dans l’assembly dans Microsoft Intermediate
Format de langue (MSIL). En d’autres termes, un assembly est à peu près l’équivalent d’un composant COM VB 6.0. Un assembly a trois options qui doivent être définies lorsque vous le créez :
- Optimisation du chargeur
- Appellation
- Emplacement
L’option d’optimisation du chargeur a trois paramètres ; domaine unique, multidomaine et hôte multidomaine. Le paramètre de domaine unique est la valeur par défaut et est le plus utilisé dans les situations côté client. Le code JIT est généralement plus petit lorsque le paramètre de domaine unique est utilisé, par rapport aux deux autres paramètres, et il n’y a pas de différence notable entre les ressources mémoire. L’exception est si l’application finit par être utilisée dans le cadre d’une configuration d’hôte multidomaine ou multidomaine, où cela fera plus mal qu’il n’aidera, comme dans une solution client/serveur.
Les paramètres d’hôte multidomaine et multidomaine s’appliquent au même concept d’utilisation multidomaine. La seule différence entre les deux est la façon dont le CLR réagira avec le code ; en multidomaine, le code est supposé être le même dans tout le domaine. Dans l’hôte multidomaine, cependant, chaque domaine héberge un code différent. Disons que vous avez un développement d’application dans lequel tous les domaines ont le nom de fichier d’assemblage, mais chacun a un code différent hébergé pour voir comment ils peuvent toujours interagir. Vous obtiendrez les meilleures performances en utilisant la routine d’optimisation d’hôte multidomaine.
Vous bénéficierez de nombreux avantages en configurant l’assemblage pour qu’il soit utilisable par plusieurs applications. Moins de ressources seront consommées, puisque le type (objet) sera déjà chargé et mappé, donc le type n’aura pas besoin d’être recréé à chaque fois que cela est nécessaire. Cependant, le résultat final du code JIT est légèrement augmenté et l’accès aux éléments statiques est plus lent, car les références statiques sont référencées indirectement.
Le nom de l’assembly peut avoir un impact sur la portée et l’utilisation par plusieurs applications. Une application à usage unique client utilise le nom qui lui a été attribué lors de sa création, mais il n’y a aucune prévention contre la collision de noms. Ainsi, afin d’éviter les conflits de noms dans un assembly dans un scénario de multiassembly, vous pouvez également donner à l’assembly un nom partagé. Le fait d’avoir un nom partagé signifie que l’assembly peut être déployé dans le Global Assembly Cache, que vous pouvez considérer comme un référentiel global d’assemblys.
Un nom partagé est composé du nom textuel de l’assemblage (le nom que vous avez créé pour lui) et d’une signature numérique. Les noms partagés sont des noms uniques en raison de l’association du nom textuel et de la signature numérique. Ce système, à son tour, permet d’éviter les collisions de noms et empêche toute personne utilisant le même nom textuel d’écrire par dessus
votre fichier, car le nom partagé est différent. Un nom partagé fournit également les informations requises pour la prise en charge de la gestion des versions par le CLR. Ces mêmes informations sont utilisées pour fournir des contrôles d’intégrité afin de garantir un niveau de confiance décent. (Pour une confiance totale, vous devez inclure une signature numérique complète avec des certificats.) Figure 2.1 illustre le fonctionnement du processus de nom partagé
Figure 2.1 Le processus de nom partagé
À partir du diagramme de nom partagé, vous pouvez voir que le nom partagé est d’abord créé dans l’assembly principal (assembly 1), puis la référence de l’assembly primaire est stockée en tant que jeton de la version dans les métadonnées de l’assembly de référence (assembly 2) , et il est finalement vérifié via le CLR. Une fois créé, un assemblage a les caractéristiques suivantes :
Contient du code que le runtime exécute PE Le code MSIL n’est pas
exécuté sans le manifeste présent. En d’autres termes, si le fichier n’est pas formaté correctement, il ne s’exécutera pas.
Un seul point d’entrée Un assemblage ne peut pas avoir plus d’un
point de départ de l’exécution par le runtime. Par exemple, vous ne pouvez pas utiliser à la fois WinMain et Main.
Unité d’exécution côte à côte Un assemblage fournit l’unité de base
nécessaires à l’exécution côte à côte.
Limite de type Chaque type déclaré dans un assembly est reconnu
comme un type de l’assemblée, non comme un type solitaire initié dans la mémoire.
Limite de sécurité L’assembly évalue les demandes d’autorisation.
Unité de déploiement de base Une application composée d’assemblys ne nécessite que les assemblys qui constituent ses fonctions principales. Tous les autres assemblys nécessaires peuvent être fournis à la demande, ce qui empêche les applications d’avoir les fichiers d’installation volumineux couramment associés aux fichiers d’exécution VB 6.0.
Limite de la portée de référence Le manifeste au sein de l’assembly dicte ce qui peut et ne peut pas se produire afin de résoudre les types et les ressources. Il énumère également la dépendance de l’assembly.
Limite de version Étant la plus petite unité versionnable du CLR, toutes les les types et les ressources dont il dispose sont également versionnés en tant qu’unité. Le manifeste décrit toutes les dépendances de version.
