Architecture des compléments d'application

Article
04/28/2010

Mise à jour : novembre 2007

S'applique à
Les informations de cette rubrique s'appliquent uniquement aux projets Visual Studio Tools pour Office et versions de Microsoft Office spécifiés. Type de projet Projets au niveau de l'application Version de Microsoft Office Version 2007 de Microsoft Office System Microsoft Office 2003 Pour plus d'informations, consultez Fonctionnalités disponibles par type d'application et de projet.

Les informations de cette rubrique s'appliquent uniquement aux projets Visual Studio Tools pour Office et versions de Microsoft Office spécifiés.

Type de projet

Projets au niveau de l'application

Version de Microsoft Office

Version 2007 de Microsoft Office System
Microsoft Office 2003

Pour plus d'informations, consultez Fonctionnalités disponibles par type d'application et de projet.

Les compléments que vous créez en utilisant Visual Studio Tools pour Office possèdent des fonctionnalités architecturales qui renforcent leur stabilité et leur sécurité et leur permettent de travailler en étroite collaboration avec Microsoft Office. Cette rubrique décrit les aspects suivants des compléments Visual Studio Tools pour Office :

Principes de base des compléments
Composants des compléments
Fonctionnement des compléments avec la version 2007 de Microsoft Office System
Fonctionnement des compléments avec Microsoft Office 2003
Comportement d'arrêt des compléments Outlook 2003

Pour obtenir des informations générales sur l'utilisation de compléments Visual Studio Tools pour Office, consultez Vue d'ensemble du développement des solutions Office et Mise en route de la programmation de compléments d'application.

Principes de base des compléments

Lorsque vous générez un complément en utilisant Visual Studio Tools pour Office, vous créez un assembly de code managé chargé par une application Microsoft Office. Une fois l'assembly chargé, le complément peut réagir aux événements déclenchés dans l'application (par exemple, lorsqu'un utilisateur clique sur un élément de menu). Le composant peut également exécuter un appel dans le modèle objet pour automatiser et étendre l'application, et il peut utiliser toutes les classes du .NET Framework.

L'assembly communique avec les composants COM de l'application à travers l'assembly PIA (Primary Interop Assembly) de celle-ci. Pour plus d'informations, consultez Assemblys PIA (Primary Interop Assembly) Office et Vue d'ensemble du développement des solutions Office.

Visual Studio Tools pour Office charge chaque complément dans un domaine d'application différent. Cela signifie qu'un complément défaillant ne peut pas entraîner l'échec d'autres compléments. Cette particularité garantit également qu'à la fermeture de l'application, tout le code est arrêté et que les assemblys sont déchargés de la mémoire. Pour plus d'informations sur les domaines d'application, consultez Vue d'ensemble des domaines d'application.

Remarque :
Les compléments créés à l'aide de Visual Studio Tools pour Office sont conçus pour être utilisés uniquement lorsque l'application Microsoft Office hôte est démarrée par un utilisateur final. Si l'application est démarrée par programme (par exemple, à l'aide de l'automatisation), le complément risque de ne pas fonctionner correctement.

Composants des compléments

Bien que l'assembly du complément soit le composant principal de celui-ci, il en existe plusieurs autres qui jouent un rôle important dans la manière dont les applications Microsoft Office découvrent et chargent les compléments.

Entrées du Registre

Les applications Microsoft Office découvrent des compléments en recherchant un jeu d'entrées du Registre. La plupart des entrées du Registre sont identiques pour les versions 2003 et 2007 de Microsoft Office, mais une clé est différente :

Les applications de la version 2007 de Microsoft Office System recherchent l'entrée Manifest sous la clé HKEY_CURRENT_USER\Software\Microsoft\Office\nom de l'application\Addins\ID du complément (ou, pour Visio, HKEY_CURRENT_USER\Software\Microsoft\Visio\Addins\ID du complément). L'entrée Manifest spécifie le chemin d'accès complet du manifeste de déploiement.
Les applications de la version 2003 de Microsoft Office System recherchent les entrées ManifestName et ManifestLocation sous la clé HKEY_CURRENT_USER\Software\Microsoft\Office\nom de l'application\Addins\ID du complément (ou, pour Visio, HKEY_CURRENT_USER\Software\Microsoft\Visio\Addins\ID du complément). Ces entrées spécifient l'emplacement et le nom du manifeste de l'application.

Lorsque vous générez votre solution, Visual Studio Tools pour Office crée toutes les entrées de registre requises sur l'ordinateur de développement afin que vous puissiez déboguer et exécuter votre complément. Pour plus d'informations, consultez Vue d'ensemble du processus de génération de solutions Office.

Pour obtenir une liste complète des entrées du Registre utilisées par les compléments, consultez Entrées du Registre pour les compléments d'application.

Remarque :
Vous pouvez déployer un complément Visual Studio Tools pour Office pour Microsoft Office 2003 de manière à le mettre à la disposition de tous les utilisateurs d'un ordinateur en créant les clés de Registre sous HKEY_LOCAL_MACHINE au lieu de HKEY_CURRENT_USER. Toutefois, vous ne pouvez pas déployer un complément Visual Studio Tools pour Office pour la version 2007 de Microsoft Office System pour tous les utilisateurs d'un ordinateur en l'enregistrant sous HKEY_LOCAL_MACHINE. Les applications de la version 2007 de Microsoft Office System ne reconnaissent que les compléments Visual Studio Tools pour Office enregistrés sous HKEY_CURRENT_USER.

Vous pouvez déployer un complément Visual Studio Tools pour Office pour Microsoft Office 2003 de manière à le mettre à la disposition de tous les utilisateurs d'un ordinateur en créant les clés de Registre sous HKEY_LOCAL_MACHINE au lieu de HKEY_CURRENT_USER. Toutefois, vous ne pouvez pas déployer un complément Visual Studio Tools pour Office pour la version 2007 de Microsoft Office System pour tous les utilisateurs d'un ordinateur en l'enregistrant sous HKEY_LOCAL_MACHINE. Les applications de la version 2007 de Microsoft Office System ne reconnaissent que les compléments Visual Studio Tools pour Office enregistrés sous HKEY_CURRENT_USER.

Manifeste de déploiement et manifeste d'application

Les compléments utilisent des manifestes de déploiement et des manifestes d'application pour identifier et charger la version la plus récente de l'assembly du complément. Le manifeste de déploiement pointe vers le manifeste d'application actuel. Le manifeste d'application pointe vers l'assembly du complément et spécifie la classe de points d'entrée à exécuter dans l'assembly. Pour plus d'informations, consultez Manifestes d'application et de déploiement dans les solutions Office.

Visual Studio Tools pour Office Runtime

Pour exécuter des compléments créés à l'aide de Visual Studio Tools pour Office, les ordinateurs des utilisateurs finaux doivent être dotés de son runtime. Celui-ci inclut des composants non managés et un jeu d'assemblys managés. Les composants non managés chargent l'assembly du complément. Les assemblys managés fournissent le modèle objet que votre code de complément utilise pour automatiser et étendre l'application hôte.

Pour plus d'informations, consultez Vue d'ensemble de Visual Studio Tools pour Office Runtime.

Fonctionnement des compléments avec la version 2007 de Microsoft Office System

Lorsqu'un utilisateur démarre une application dans la version 2007 de Microsoft Office System, celle-ci utilise le manifeste de déploiement et le manifeste d'application pour localiser et charger la version la plus récente de l'assembly du complément. L'illustration suivante montre l'architecture de base de ces compléments.

Architecture des compléments pour la version 2007 de Microsoft Office System

Processus de chargement

Les étapes suivantes se produisent lorsqu'un utilisateur démarre une application :

L'application recherche dans le Registre des entrées identifiant des compléments créés à l'aide de Visual Studio Tools pour Office.
Si l'application trouve de telles entrées, elle charge VSTOEE.dll, qui charge à son tour VSTOLoader.dll. Ces DLL non managées sont les composants de chargement de Microsoft Visual Studio Tools pour Microsoft Office System (version 3.0 Runtime). Pour plus d'informations, consultez Vue d'ensemble de Visual Studio Tools pour Office Runtime.
VSTOLoader.dll charge le .NET Framework et démarre la partie managée du runtime de Visual Studio Tools pour Office.
Le runtime Visual Studio Tools pour Office recherche les mises à jour du manifeste et télécharge les manifestes d'application et de déploiement les plus récents.
Le runtime Visual Studio Tools pour Office effectue une série de contrôles de sécurité. Pour plus d'informations, consultez Sécurité dans les solutions Office (Office System 2007).
Si le complément est approuvé de manière à pouvoir s'exécuter, le runtime Visual Studio Tools pour Office utilise les manifestes de déploiement et d'application pour rechercher les mises à jour de l'assembly. Si une nouvelle version de l'assembly est disponible, le runtime la télécharge dans le cache ClickOnce de l'ordinateur client. Pour plus d'informations, consultez Déploiement de solutions Office (Office System 2007).
Le runtime Visual Studio Tools pour Office crée un nouveau domaine d'application dans lequel charger l'assembly du complément.
Le runtime Visual Studio Tools pour Office charge l'assembly du complément dans le domaine d'application.
Le runtime Visual Studio Tools pour Office appelle la méthode RequestComAddInAutomationService dans votre complément, si vous l'avez substituée.

Vous pouvez également substituer cette méthode pour exposer un objet de votre complément à d'autres solutions Microsoft Office. Pour plus d'informations, consultez Appel de code dans des compléments d'application à partir d'autres solutions Office.
Le runtime Visual Studio Tools pour Office appelle la méthode RequestService dans votre complément, si vous l'avez substituée.

Vous pouvez également substituer cette méthode pour étendre une fonctionnalité dans la version 2007 de Microsoft Office System en retournant un objet qui implémente une interface d'extensibilité. Pour plus d'informations, consultez Personnalisation des fonctionnalités de l'interface utilisateur à l'aide d'interfaces d'extensibilité.
Le runtime Visual Studio Tools pour Office appelle la méthode ThisAddIn_Startup dans votre complément. Cette méthode est le gestionnaire d'événements par défaut pour l'événement Startup. Pour plus d'informations, consultez Événements de projet Visual Studio Tools pour Office.

Remarque :
Le runtime Visual Studio Tools pour Office initie des appels distincts à la méthode RequestService pour chaque interface d'extensibilité prise en charge par l'application hôte. Bien que le premier appel à la méthode RequestService se produise généralement avant l'appel à la méthode ThisAddIn_Startup, votre complément ne doit pas former d'hypothèses quant au moment où la méthode RequestService sera appelée, ou au nombre de fois où elle sera appelée.

Le runtime Visual Studio Tools pour Office initie des appels distincts à la méthode RequestService pour chaque interface d'extensibilité prise en charge par l'application hôte. Bien que le premier appel à la méthode RequestService se produise généralement avant l'appel à la méthode ThisAddIn_Startup, votre complément ne doit pas former d'hypothèses quant au moment où la méthode RequestService sera appelée, ou au nombre de fois où elle sera appelée.

Fonctionnement des compléments avec Microsoft Office 2003

Lorsqu'un utilisateur démarre une application Microsoft Office, celle-ci utilise des informations du manifeste d'application (et, éventuellement, du manifeste de déploiement) pour charger l'assembly du complément. L'illustration suivante montre l'architecture de base d'un complément pour une application Microsoft Office 2003.

Architecture des compléments pour Microsoft Office 2003

Processus de chargement

Les étapes suivantes se produisent lorsqu'un utilisateur démarre une application :

L'application recherche dans le Registre des entrées identifiant des compléments créés à l'aide de Visual Studio Tools pour Office.
Si l'application trouve de telles entrées, elle charge VSTOEE.dll, qui charge à son tour AddinLoader.dll. Ces DLL non managées sont les composants de chargement de Visual Studio 2005 Tools pour Office Second Edition Runtime. Pour plus d'informations, consultez Vue d'ensemble de Visual Studio Tools pour Office Runtime.
AddinLoader.dll charge le .NET Framework et démarre la partie managée du runtime de Visual Studio Tools pour Office.
Le runtime Visual Studio Tools pour Office crée un domaine d'application, définit la stratégie de celui-ci de manière à ne pas approuver la zone Poste de travail et recherche une stratégie pour l'assembly du complément dans le magasin de stratégies de sécurité d'accès du code.
Le .NET Framework valide la preuve présentée par l'assembly sur la base de la stratégie du domaine d'application. Si la validation échoue, une erreur est déclenchée. Si la validation réussit, le processus continue.
Si le complément utilise un manifeste de déploiement, le runtime Visual Studio Tools pour Office l'utilise pour rechercher les mises à jour de l'assembly. Si des mises à jour sont nécessaires, elles sont effectuées à ce stade.
Le runtime Visual Studio Tools pour Office charge l'assembly du complément dans le nouveau domaine d'application.
Le runtime Visual Studio Tools pour Office appelle la méthode RequestComAddInAutomationService dans votre complément, si vous l'avez substituée.

Vous pouvez également substituer cette méthode pour exposer un objet de votre complément à d'autres solutions Microsoft Office. Pour plus d'informations, consultez Appel de code dans des compléments d'application à partir d'autres solutions Office.
Le runtime Visual Studio Tools pour Office appelle la méthode ThisAddIn_Startup dans votre complément. Cette méthode est le gestionnaire d'événements par défaut pour l'événement Startup. Pour plus d'informations, consultez Événements de projet Visual Studio Tools pour Office.

Comportement d'arrêt des compléments Outlook 2003

Si vous effectuez une migration d'un complément COM existant d'Outlook 2003 (autrement dit, un complément qui implémente directement l'interface IDTExtensibility2) vers Visual Studio Tools pour Office, supprimez tout code conçu pour contourner les problèmes d'arrêt potentiels. Sinon, ce code risque d'entrer en conflit avec le processus d'arrêt des compléments Outlook 2003 créés à l'aide de Visual Studio Tools pour Office, ou votre complément risque d'être déchargé prématurément.

Remarque :
Le comportement décrit dans cette section ne s'applique pas aux compléments Outlook 2007. Outlook 2007 appelle toujours la méthode OnDisconnection dans un complément, même si le complément possède encore des références à des objets Outlook.

Contexte du problème d'arrêt

Tant qu'un complément COM possède une référence à un ou plusieurs objets Outlook, Outlook 2003 n'appelle pas la méthode OnDisconnection dans le complément. Si le complément comportent des références d'objet qui ne sont nettoyées que dans la méthode OnDisconnection, Outlook 2003 n'appelle jamais la méthode OnDisconnection. Par conséquent, le complément n'est jamais déchargé et Outlook 2003 ne s'arrête jamais.

Comment Visual Studio Tools pour Office résout le problème d'arrêt

Les compléments Outlook 2003 créés à l'aide de Visual Studio Tools pour Office sont déchargés d'une manière qui permet d'éviter ce problème potentiel. Le runtime Visual Studio Tools pour Office déclenche l'événement Shutdown du complément et décharge le domaine d'application du complément si celui-ci ne possède pas de références aux objets Explorer ou Inspector lorsque l'une de ces situations se produit :

La méthode Quit est appelée.
L'événement Close d'un objet Explorer ou Inspector est déclenché.

Lorsque le domaine d'application est déchargé, toutes les références en suspens à d'autres objets Outlook sont nettoyées. Outlook 2003 peut alors arrêter le complément et se fermer.