Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Une application d’interopérabilité inclut généralement un assembly client .NET, un ou plusieurs assemblys d’interopérabilité représentant des bibliothèques de types COM distinctes et un ou plusieurs composants COM inscrits. Visual Studio et le Kit de développement logiciel (SDK) Windows fournissent des outils permettant d’importer et de convertir une bibliothèque de types en assembly d’interopérabilité, comme indiqué dans l’importation d’une bibliothèque de types en tant qu’assembly. Il existe deux façons de déployer une application d’interopérabilité :
En utilisant des types d’interopérabilité incorporés : à partir du .NET Framework 4, vous pouvez demander au compilateur d’incorporer des informations de type à partir d’un assembly d’interopérabilité dans votre exécutable. Le compilateur incorpore uniquement les informations de type que votre application utilise. Vous n’avez pas à déployer l’assembly d’interopérabilité avec votre application. Il s’agit de la technique recommandée.
En déployant des assemblys d’interopérabilité : vous pouvez créer une référence standard à un assembly d’interopérabilité. Dans ce cas, l’assembly d’interopérabilité doit être déployé avec votre application. Si vous utilisez cette technique et que vous n’utilisez pas de composant COM privé, référencez toujours l’assembly PIA (Primary Interop Assembly) publié par l’auteur du composant COM que vous envisagez d’incorporer dans votre code managé. Pour plus d’informations sur la production et l’utilisation d’assemblys d’interopérabilité primaire, consultez Assemblys d’interopérabilité primaire.
Si vous utilisez des types d’interopérabilité incorporés, le déploiement est simple et simple. Il n’y a rien de spécial à faire. Le reste de cet article décrit les scénarios de déploiement d’assemblys d’interopérabilité avec votre application.
Déploiement des assemblys d’interopérabilité
Les assemblies peuvent porter des noms forts. Un assembly avec nom fort inclut la clé publique de l’éditeur, qui fournit une identité unique. Les assemblys générés par l’importateur de bibliothèque de types (Tlbimp.exe) peuvent être signés par l’éditeur à l’aide de l’option /keyfile . Vous pouvez installer des assemblys signés dans le Global Assembly Cache. Les assemblages non signés doivent être installés sur la machine de l’utilisateur en tant qu'assemblages privés.
Assemblys privés
Pour installer un assembly à utiliser en privé, l’exécutable de l’application et l’assembly d’interopérabilité qui contient des types COM importés doivent être installés dans la même structure de répertoires. L’illustration suivante montre un assembly d’interopérabilité non signé à utiliser en privé par Client1.exe et Client2.exe, qui résident dans des répertoires d’application distincts. L’assembly d’interopérabilité, appelé LOANLib.dll dans cet exemple, est installé deux fois.
Tous les composants COM associés à l’application doivent être installés dans le Registre Windows. Si Client1.exe et Client2.exe dans l’illustration sont installés sur différents ordinateurs, vous devez inscrire les composants COM sur les deux ordinateurs.
Assemblys partagés
Les assemblys partagés par plusieurs applications doivent être installés dans un référentiel centralisé appelé Global Assembly Cache. Les clients .NET peuvent accéder à la même copie de l’assembly d’interopérabilité, qui est signé et installé dans le Global Assembly Cache. Pour plus d’informations sur la production et l’utilisation d’assemblys d’interopérabilité primaire, consultez Assemblys d’interopérabilité primaire.
Voir aussi
Collaborer avec nous sur GitHub
La source de ce contenu se trouve sur GitHub, où vous pouvez également créer et examiner les problèmes et les demandes de tirage. Pour plus d’informations, consultez notre guide du contributeur.
