Pour atteindre tous ces objectifs, il faut mainteant introduire une nouvelle notion, la notion d'assembly.
Une assembly est un bloc d'assemblage minimum pour construire une application. Cela peut être une Dll ou bien un executable. On peut la comparer à un fichier Jar de Java. Une assembly est donc la plus petite unité d'execution que l'on trouve dans le fonctionnement d'une application pour le framework. Les assembly sont donc des unités de déploiement, de controle de version, de réutilisabilité, de visibilité de types et enfin de controle de la sécurité. Une assembly est un pool de types et de ressources qui sont compilés pour fonctionner ensembles et forme ainsi une unité de fonctionnement.
Cette notion d'assembly a été introduite pour simplifier le déploiement d'application et éviter les conflits de versions que l'on est à même de rencontrer lorsque l'on développe des applications basées sur la réutilisation de composants. En effet, avant les assembly, la compatibilité entre les différentes versions d'une librairie, par exemple, n'était assurée que par le fait que les versions futurs de la librairie devaient respecter ce que l'on appelle la 'compatibilité ascendante' pour la simple raison que l'on ne pouvait pas éxécuter plus d'une version de cette librairie en même temps sur le système. Le problème qui pouvait survenir, et qui vous est surement déjà arrivé, est qu'à l'installation d'une nouvelle application, celle-ci remplace une Dll partagée par d'autres applications et voila que ces autres applications ne fonctionnent plus faute de la bonne version de la Dll en question !!
Aujourd'hui, le couplage CLR-Assembly supprime définitivement ce problème. Le développeur peut définir des règles de versionning sur les composants qu'il utilise pour développer son application. De plus le CLR fournit la possibilité d'éxécuter plusieurs versions d'un même composant en même temps; c'est ce que l'on a appelé l'éxécution "cote-à-cote".
Une assembly peut etre construite de différentes manières : soit dans un fichier unique, soit dans plusieurs fichiers séparés. Dans les deux cas, une assembly contient :
- un manifest : décrit les méta-données de l'assembly.
- les méta-données : décrivent les types utilisés dans l'assembly.
- le code IL : l'Intermediate Language (expliqué ailleurs dans ce site).
- les ressources utilisées : images, ...
- la liste des fichiers qui la compose, pour une assembly en plusieurs fichiers.
![]() |
![]() |
On distingue deux types d'assembly; les assembly privées et les assembly publiques. Rien ne les différencie, c'est seulement leur mode d'utilisation qui fait la différence. Les assembly privées sont des composants dédiés, spécifiques à une application, alors que les assembly publiques sont pour la plupart des composant partagés dans le but de les réutiliser. Ce sont pour ces raisons que les assembly privées sont généralement installées dans l'arborescence d'installation du programme pour lequel elle est dédiée, alors que les assembly publiques sont placées avec les composants utilisés par le système dans un cache prévu à cet effet.
L'éxécution de plusieurs versions d'un même composant est possible grâce à un cache spécial concu pour gérer ce type d'éxécution. C'est le GAC ou Global Assembly Cache. Ce cache se présente sous la forme d'un répertoire dans le système de fichiers qui est C:\WINDOWS\assembly pour la plupart des installations Windows. Vous me direz, comment est-il possible d'avoir plusieurs versions d'un même fichier dans un répertoire, alors que l'on ne peut pas avoir deux fichiers qui portent le même nom ? En fait c'est très simple ! les assembly présentes dans ce dossier sont présentées sous windows de facon décorée et c'est pour cette raison que l'on ne peut pas copier vulgairement une assembly que l'on voudrait partager dans ce répertoire. Pour installer une assembly dans ce répertoire il exite plusieurs facons de procéder :
- soit en utilisant l'utilitaire Gacutil.exe, fourni avec le FrameWork .Net SDK
- soit en utilisant un programme d'installation prévu pour travailler avec le GAC
- soit en utilisant le drag'n drop de windows qui se charge d'effectuer les opérations nécessaires pour installer correctement la nouvelle assembly.
En effet, ces trois utilitaires se servent des informations contenues dans l'assembly pour construire une arborescence correspondant à la version de l'assembly pour permettre l'utilisation de plusieurs versions d'une même assembly.
Les assembly présentes dans le GAC doivent être ce que l'on appelle des assembly à nommage fort. C'est à dire qu'il y a un mécanisme de clè privée/ clé publique contruit à partir du nom de l'assembly, de sa version et de sa culture (si elle est définie), pour garantir l'unicité d'une version ainsi que son intégrité. Cela permets d'éviter le piratage de fichiers par une personne malveillante.