Génération d'assemblys côte à côte C/C++

Un assembly côte à côte est une collection de ressources ( un groupe de DLL, de classes Windows, de serveurs COM, de bibliothèques de types ou d’interfaces) disponible pour une application à utiliser au moment de l’exécution. L’avantage principal de repacking des DLL dans les assemblys est que plusieurs versions d’assemblys peuvent être utilisées par les applications en même temps et qu’il est possible de traiter les assemblys actuellement installés en cas de mise à jour de mise à jour.

Une application C++ peut utiliser une ou plusieurs DLL dans différentes parties de l’application. Au moment de l’exécution, les DLL sont chargées dans le processus principal et le code requis est exécuté. L’application s’appuie sur le système d’exploitation pour localiser les DLL demandées, comprendre ce que d’autres DLL dépendantes doivent être chargées, puis les charger avec la DLL demandée. Sur les versions des systèmes d’exploitation Windows antérieures à Windows XP, Windows Server 2003 et Windows Vista, le chargeur de système d’exploitation recherche des DLL dépendantes dans le dossier local de l’application ou un autre dossier spécifié sur le chemin du système. Sur Windows XP, Windows Server 2003 et Windows Vista, le chargeur du système d’exploitation peut également rechercher des DLL dépendantes à l’aide d’un fichier manifeste et rechercher des assemblys côte à côte qui contiennent ces DLL.

Par défaut, lorsqu’une DLL est générée avec Visual Studio, elle a un manifeste d’application incorporé en tant que ressource RT_MANIFEST avec l’ID égal à 2. Tout comme pour un exécutable, ce manifeste décrit les dépendances de cette DLL sur d’autres assemblys. Cela suppose que la DLL ne fait pas partie d’un assembly côte à côte et d’applications qui dépendent de cette DLL ne vont pas utiliser un manifeste d’application pour le charger, mais s’appuient plutôt sur le chargeur du système d’exploitation pour rechercher cette DLL sur le chemin du système.

Remarque

Il est important qu’une DLL utilise un manifeste d’application pour que le manifeste soit incorporé en tant que ressource dont l’ID est égal à 2. Si la DLL est chargée dynamiquement au moment de l’exécution (par exemple, à l’aide de la fonction LoadLibrary ), le chargeur du système d’exploitation charge les assemblys dépendants spécifiés dans le manifeste de la DLL. Un manifeste d’application externe pour les DLL n’est pas vérifié pendant un LoadLibrary appel. Si le manifeste n’est pas incorporé, le chargeur peut tenter de charger des versions incorrectes d’assemblys ou de trouver des assemblys dépendants.

Une ou plusieurs DLL associées peuvent être repackagenées dans un assembly côte à côte avec un manifeste d’assembly correspondant, qui décrit les fichiers qui forment l’assembly, ainsi que la dépendance de l’assembly sur d’autres assemblys côte à côte.

Remarque

Si un assembly contient une DLL, il est recommandé d’incorporer le manifeste d’assembly dans cette DLL en tant que ressource dont l’ID est égal à 1 et de donner le même nom à l’assembly privé que la DLL. Par exemple, si le nom de la DLL est mylibrary.dll, la valeur de l’attribut name utilisé dans l’élément <assemblyIdentity> du manifeste peut également être mylibrary. Dans certains cas, lorsqu’une bibliothèque a une extension autre que .dll (par exemple, un projet ActiveX Controls MFC crée une bibliothèque .ocx) un manifeste d’assembly externe peut être créé. Dans ce cas, le nom de l’assembly et de son manifeste doit être différent du nom de la DLL (par exemple, MyAssembly, MyAssembly.manifest et mylibrary.ocx). Toutefois, il est toujours recommandé de renommer ces bibliothèques pour avoir la extension.dll et incorporer le manifeste en tant que ressource pour réduire le coût de maintenance futur de cet assembly. Pour plus d’informations sur la façon dont le système d’exploitation recherche des assemblys privés, consultez Séquence de recherche d’assembly.

Cette modification peut autoriser le déploiement de DLL correspondantes en tant qu’assembly privé dans un dossier local d’application ou en tant qu’assembly partagé dans le cache d’assembly WinSxS. Plusieurs étapes doivent être suivies pour obtenir un comportement d’exécution correct de ce nouvel assembly ; ils sont décrits dans Instructions pour la création d’assemblys côte à côte. Une fois qu’un assembly est correctement créé, il peut être déployé en tant qu’assembly partagé ou privé avec une application qui en dépend. Lors de l’installation d’assemblys côte à côte en tant qu’assembly partagé, vous pouvez suivre les instructions décrites dans l’installation des assemblys Win32 pour le partage côte à côte sur Windows XP ou utiliser des modules de fusion. Lors de l’installation d’assemblys côte à côte en tant qu’assembly privé, vous pouvez simplement copier la DLL, les ressources et le manifeste d’assembly correspondants dans le cadre du processus d’installation dans le dossier local de l’application sur l’ordinateur cible, ce qui garantit que cet assembly peut être trouvé par le chargeur au moment de l’exécution (voir Séquence de recherche d’assembly). Une autre façon consiste à utiliser Windows Installer et à suivre les instructions décrites dans l’installation d’assemblys Win32 pour l’utilisation privée d’une application sur Windows XP.

Voir aussi

Génération d’applications isolées C/C++
Génération d’applications isolées et d’assemblys côte à côte C/C++