Architektur von Add-Ins auf Anwendungsebene

Artikel
04/28/2010

Aktualisiert: November 2007

Betrifft
Die Informationen in diesem Thema gelten nur für die angegebenen Projekte und Versionen von Visual Studio Tools for Office von Microsoft Office. Projekttyp Projekte auf Anwendungsebene Microsoft Office-Version 2007 Microsoft Office System Microsoft Office 2003 Weitere Informationen hierzu finden Sie unter Verfügbare Features nach Anwendung und Projekttyp.

Die Informationen in diesem Thema gelten nur für die angegebenen Projekte und Versionen von Visual Studio Tools for Office von Microsoft Office.

Projekttyp

Projekte auf Anwendungsebene

Microsoft Office-Version

2007 Microsoft Office System
Microsoft Office 2003

Weitere Informationen hierzu finden Sie unter Verfügbare Features nach Anwendung und Projekttyp.

Die mithilfe von Visual Studio Tools for Office erstellten Add-Ins besitzen Architekturfeatures, die Stabilität und Sicherheit hervorheben und ein enges Zusammenarbeiten der Add-Ins mit Microsoft Office ermöglichen. In diesem Thema werden die folgenden Aspekte von Visual Studio Tools for Office-Add-Ins beschrieben:

Add-Ins
Komponenten von Add-Ins
Wie Add-Ins mit 2007 Microsoft Office System verwendet werden
Wie Add-Ins mit Microsoft Office 2003 verwendet werden
Verhalten von Outlook 2003-Add-Ins beim Beenden

Allgemeine Informationen zur Verwendung von Visual Studio Tools for Office-Add-Ins finden Sie unter Übersicht über die Entwicklung von Office-Projektmappen und unter Erste Schritte beim Programmieren von Add-Ins auf Anwendungsebene.

Add-Ins

Wenn Sie mit Visual Studio Tools for Office ein Add-In erstellen, erstellen Sie eine Assembly mit verwaltetem Code, die von einer Microsoft Office-Anwendung geladen wird. Nach dem Laden der Assembly, kann das Add-In auf Ereignisse reagieren, die in der Anwendung ausgelöst werden (z. B. wenn ein Benutzer auf ein Menüelement klickt). Das Add-In kann auch einen Aufruf an das Objektmodell ausführen, um die Anwendung zu automatisieren und zu erweitern, und das Add-In kann jede der Klassen in .NET Framework verwenden.

Die Assembly verwendet die primäre Interop-Assembly der Anwendung, um mit den COM-Komponenten der Anwendung zu kommunizieren. Weitere Informationen finden Sie unter Primäre Interopassemblys in Office und unter Übersicht über die Entwicklung von Office-Projektmappen.

Visual Studio Tools for Office lädt jedes Add-In in einer anderen Anwendungsdomäne. So kann kein Add-In, das sich falsch verhält, bewirken, dass andere Add-Ins fehlschlagen. Dies sorgt dafür, dass beim Schließen der Anwendung der gesamte Code beendet wird und die Assemblys aus dem Speicher entladen werden. Weitere Informationen zu Anwendungsdomänen finden Sie unter Übersicht über Anwendungsdomänen.

Hinweis:
Add-Ins, die mit Visual Studio Tools for Office erstellt werden, sollen nur dann verwendet werden, wenn die Microsoft Office-Hostanwendung von einem Endbenutzer gestartet wird. Wird die Anwendung programmgesteuert gestartet (beispielsweise durch Automatisierung), verhält sich das Add-In unter Umständen nicht so, wie erwartet.

Komponenten von Add-Ins

Obwohl es sich bei der Add-In-Assembly um die Hauptkomponente handelt, gibt es zudem mehrere andere Komponenten, die beeinflussen, wie Microsoft Office-Anwendungen Add-Ins finden und laden.

Registrierungseinträge

Microsoft Office-Anwendungen ermitteln Add-Ins, indem sie nach einem Satz von Registrierungseinträgen suchen. Die meisten Registrierungseinträge sind für die Versionen 2003 und 2007 von Microsoft Office gleich. Ein Schlüssel ist jedoch unterschiedlich:

Anwendungen in 2007 Microsoft Office System suchen nach dem Manifest-Eintrag unter dem Schlüssel HKEY_CURRENT_USER\Software\Microsoft\Office\application name\Addins\add-in ID (oder für Visio: HKEY_CURRENT_USER\Software\Microsoft\Visio\Addins\add-in ID). Der Manifest-Eintrag gibt den vollständigen Pfad des Bereitstellungsmanifests an.
Microsoft Office 2003-Anwendungen suchen nach dem ManifestName-Eintrag und dem ManifestLocation-Eintrag unter dem Schlüssel HKEY_CURRENT_USER\Software\Microsoft\Office\application name\Addins\add-in ID (oder für Visio: HKEY_CURRENT_USER\Software\Microsoft\Visio\Addins\add-in ID). Diese Einträge geben den Speicherort und den Namen des Anwendungsmanifests an.

Beim Erstellen der Projektmappe erstellt Visual Studio Tools for Office alle erforderlichen Registrierungseinträge auf dem Entwicklungscomputer, sodass Sie das Add-In debuggen und ausführen können. Weitere Informationen finden Sie unter Übersicht über das Erstellen von Office-Projektmappen.

Eine vollständige Liste der von Add-Ins verwendeten Registrierungseinträge finden Sie unter Registrierungseinträge für Add-Ins auf Anwendungsebene.

Hinweis:
Sie können ein Visual Studio Tools for Office-Add-In für Microsoft Office 2003 bereitstellen, sodass es für alle Benutzer eines Computers verfügbar ist, indem Sie die Registrierungsschlüssel unter HKEY_LOCAL_MACHINE anstatt unter HKEY_CURRENT_USER erstellen. Sie können jedoch kein Visual Studio Tools for Office-Add-In für 2007 Microsoft Office System für alle Benutzer eines Computers bereitstellen, indem Sie das Add-In unter HKEY_LOCAL_MACHINE registrieren. Anwendungen in 2007 Microsoft Office System erkennen nur Visual Studio Tools for Office-Add-Ins, die unter HKEY_CURRENT_USER registriert werden.

Sie können ein Visual Studio Tools for Office-Add-In für Microsoft Office 2003 bereitstellen, sodass es für alle Benutzer eines Computers verfügbar ist, indem Sie die Registrierungsschlüssel unter HKEY_LOCAL_MACHINE anstatt unter HKEY_CURRENT_USER erstellen. Sie können jedoch kein Visual Studio Tools for Office-Add-In für 2007 Microsoft Office System für alle Benutzer eines Computers bereitstellen, indem Sie das Add-In unter HKEY_LOCAL_MACHINE registrieren. Anwendungen in 2007 Microsoft Office System erkennen nur Visual Studio Tools for Office-Add-Ins, die unter HKEY_CURRENT_USER registriert werden.

Bereitstellungsmanifest und Anwendungsmanifest

Add-Ins verwenden Bereitstellungs- und Anwendungsmanifeste, um die aktuelle Version der Add-In-Assembly zu identifizieren und zu laden. Das Bereitstellungsmanifest verweist auf das aktuelle Anwendungsmanifest. Das Anwendungsmanifest verweist auf die Add-In-Assembly und gibt die Einstiegspunktklasse an, die in der Assembly ausgeführt wird. Weitere Informationen finden Sie unter Anwendungs- und Bereitstellungsmanifeste in Office-Projektmappen.

Visual Studio Tools for Office Runtime

Um Add-Ins auszuführen, die mit Visual Studio Tools for Office erstellt wurden, muss auf dem Endbenutzercomputer die Visual Studio Tools for Office-Laufzeit installiert sein. Die Laufzeit schließt nicht verwaltete Komponenten und einen Satz verwalteter Assemblys ein. Die nicht verwalteten Komponenten laden die Add-In-Assembly. Die verwalteten Assemblys enthalten das Objektmodell, das der Add-In-Code verwendet, um die Hostanwendung zu automatisieren und zu erweitern.

Weitere Informationen finden Sie unter Übersicht über die Visual Studio Tools for Office-Laufzeit.

Wie Add-Ins mit 2007 Microsoft Office System verwendet werden

Wenn ein Benutzer eine Anwendung in 2007 Microsoft Office System startet, verwendet die Anwendung das Bereitstellungsmanifest und das Anwendungsmanifest, um die aktuelle Version der Add-In-Assembly zu finden und zu laden. In der folgenden Abbildung wird die grundlegende Architektur dieser Add-Ins dargestellt.

Architektur eines Add-Ins für 2007 Microsoft Office System

Ladevorgang

Die folgenden Schritte werden ausgeführt, wenn ein Benutzer eine Anwendung startet:

Die Anwendung überprüft die Registrierung auf Einträge, die Add-Ins identifizieren, die mithilfe von Visual Studio Tools for Office erstellt wurden.
Wenn die Anwendung diese Registrierungseinträge findet, lädt die Anwendung die Datei VSTOEE.dll, die wiederum die Datei VSTOLoader.dll lädt. Hierbei handelt es sich um nicht verwaltete DLLs, die die Ladeprogrammkomponenten für Microsoft Visual Studio Tools für Microsoft Office System (Version 3.0-Laufzeit) sind. Weitere Informationen finden Sie unter Übersicht über die Visual Studio Tools for Office-Laufzeit.
VSTOLoader.dll lädt .NET Framework und startet den verwalteten Teil der Visual Studio Tools for Office-Laufzeit.
Die Visual Studio Tools for Office-Laufzeit überprüft die Manifestupdates und lädt die aktuellsten Anwendungs- und die Bereitstellungsmanifeste herunter.
Die Visual Studio Tools for Office-Laufzeit führt eine Reihe von Sicherheitsüberprüfungen aus. Weitere Informationen finden Sie unter Sicherheit in Office-Projektmappen (2007 System).
Wenn das Add-In vertrauenswürdig ist und ausgeführt werden darf, verwendet die Visual Studio Tools for Office-Laufzeit das Bereitstellungsmanifest und das Anwendungsmanifest, um nach Assemblyaktualisierungen zu suchen. Wenn eine neue Version der Assembly verfügbar ist, lädt die Laufzeit die neue Version der Assembly in den ClickOnce-Cache auf dem Clientcomputer. Weitere Informationen hierzu finden Sie unter Bereitstellen von Office-Projektmappen (2007 System).
Die Visual Studio Tools for Office-Laufzeit erstellt eine neue Anwendungsdomäne, in der die Add-In-Assembly geladen wird.
Die Add-In-Assembly wird von der Visual Studio Tools for Office-Laufzeit in die Anwendungsdomäne geladen.
Die Visual Studio Tools for Office-Laufzeit ruft die RequestComAddInAutomationService-Methode im Add-In auf, wenn Sie sie überschrieben haben.

Sie können diese Methode wahlweise überschreiben, um ein Objekt im Add-In für andere Microsoft Office-Projektmappen verfügbar zu machen. Weitere Informationen finden Sie unter Aufrufen von Code in Add-Ins auf Anwendungsebene von anderen Office-Projektmappen.
Die Visual Studio Tools for Office-Laufzeit ruft die RequestService-Methode im Add-In auf, wenn Sie sie überschrieben haben.

Sie können diese Methode wahlweise überschreiben, um ein Feature in 2007 Microsoft Office System zu erweitern, indem Sie ein Objekt zurückgeben, welches eine Erweiterbarkeitsschnittstelle implementiert. Weitere Informationen finden Sie unter Anpassen von Features der Benutzeroberfläche mithilfe von Erweiterungsschnittstellen.
Die Visual Studio Tools for Office-Laufzeit ruft die ThisAddIn_Startup-Methode im Add-In auf. Diese Methode ist der Standardereignishandler für das Startup-Ereignis. Weitere Informationen finden Sie unter Visual Studio Tools for Office-Projektereignisse.

Hinweis:
Die Visual Studio Tools for Office-Laufzeit sendet für jede Erweiterbarkeitsschnittstelle, die von der Hostanwendung unterstützt wird, separate Aufrufe an die RequestService-Methode. Obwohl der erste Aufruf der RequestService-Methode in der Regel vor dem Aufruf der ThisAddIn_Startup-Methode ausgeführt wird, sollte das Add-In keine Annahmen darüber anstellen, wann oder wie oft die RequestService-Methode aufgerufen wird.

Die Visual Studio Tools for Office-Laufzeit sendet für jede Erweiterbarkeitsschnittstelle, die von der Hostanwendung unterstützt wird, separate Aufrufe an die RequestService-Methode. Obwohl der erste Aufruf der RequestService-Methode in der Regel vor dem Aufruf der ThisAddIn_Startup-Methode ausgeführt wird, sollte das Add-In keine Annahmen darüber anstellen, wann oder wie oft die RequestService-Methode aufgerufen wird.

Wie Add-Ins mit Microsoft Office 2003 verwendet werden

Wenn ein Benutzer eine Microsoft Office-Anwendung startet, verwendet die Anwendung Informationen in dem Anwendungsmanifest (und wahlweise in dem Bereitstellungsmanifest), um die Add-In-Assembly zu laden. In der folgenden Abbildung wird die grundlegende Architektur eines Add-Ins für eine Microsoft Office 2003-Anwendung dargestellt.

Architektur eines Add-Ins für Microsoft Office 2003

Ladevorgang

Die folgenden Schritte werden ausgeführt, wenn ein Benutzer eine Anwendung startet:

Die Anwendung überprüft die Registrierung auf Einträge, die Add-Ins identifizieren, die mithilfe von Visual Studio Tools for Office erstellt wurden.
Wenn die Anwendung diese Registrierungseinträge findet, lädt die Anwendung die Datei VSTOEE.dll, die wiederum die Datei AddinLoader.dll lädt. Hierbei handelt es sich um nicht verwaltete DLLs, die die Ladeprogrammkomponenten für Laufzeit für Visual Studio 2005 Tools for Office Second Edition sind. Weitere Informationen finden Sie unter Übersicht über die Visual Studio Tools for Office-Laufzeit.
AddinLoader.dll lädt .NET Framework und startet den verwalteten Teil der Visual Studio Tools for Office-Laufzeit.
Die Visual Studio Tools for Office-Laufzeit erstellt eine neue Anwendungsdomäne, legt eine Richtlinie auf der Anwendungsdomäne fest, die besagt, dass die Arbeitsplatzzone nicht vertrauenswürdig ist, und überprüft, ob es unter den Codezugriffssicherheits-Richtlinien eine Richtlinie für die Add-In-Assembly gibt.
.NET Framework überprüft, ob der von der Assembly vorgelegte Beweis der Richtlinie der Anwendungsdomäne entspricht. Wenn dies nicht der Fall ist, wird ein Fehler ausgelöst. Andernfalls wird der Prozess fortgesetzt.
Wenn das Add-In ein Bereitstellungsmanifest verwendet, sucht die Visual Studio Tools for Office-Laufzeit mit diesem Manifest nach Assemblyupdates. Wenn Aktualisierungen erforderlich sind, werden diese nun ausgeführt.
Die Add-In-Assembly wird von der Visual Studio Tools for Office-Laufzeit in die neue Anwendungsdomäne geladen.
Die Visual Studio Tools for Office-Laufzeit ruft die RequestComAddInAutomationService-Methode im Add-In auf, wenn Sie sie überschrieben haben.

Sie können diese Methode wahlweise überschreiben, um ein Objekt im Add-In für andere Microsoft Office-Projektmappen verfügbar zu machen. Weitere Informationen finden Sie unter Aufrufen von Code in Add-Ins auf Anwendungsebene von anderen Office-Projektmappen.
Die Visual Studio Tools for Office-Laufzeit ruft die ThisAddIn_Startup-Methode im Add-In auf. Diese Methode ist der Standardereignishandler für das Startup-Ereignis. Weitere Informationen finden Sie unter Visual Studio Tools for Office-Projektereignisse.

Verhalten von Outlook 2003-Add-Ins beim Beenden

Wenn Sie ein vorhandenes Outlook 2003-COM-Add-In (d. h. ein Add-In, mit dem die IDTExtensibility2-Schnittstelle direkt implementiert wird) zu Visual Studio Tools for Office migrieren, entfernen Sie sämtlichen Code, der zum Umgehen potenzieller Probleme beim Beenden entwickelt wurde. Andernfalls kann dies zu einem Konflikt zwischen dem Code und dem Beendigungsvorgang von Outlook 2003-Add-Ins führen, die mit Visual Studio Tools for Office erstellt wurden, oder das Add-In wird möglicherweise vorzeitig beendet.

Hinweis:
Das in diesem Abschnitt beschriebene Verhalten bezieht sich nicht auf Outlook 2007-Add-Ins. In Outlook 2007 wird immer die OnDisconnection-Methode in einem Add-In aufgerufen, selbst wenn das Add-In noch über Verweise auf Outlook-Objekte verfügt.

Hintergrundinformationen zum Problem beim Beenden

Solange ein COM-Add-In über einen Verweis auf mindestens ein Outlook-Objekt verfügt, ruft Outlook 2003 nicht die OnDisconnection-Methode in dem Add-In auf. Wenn das Add-In über Objektverweise verfügt, die nur in der OnDisconnection-Methode bereinigt werden, ruft Outlook 2003 nie die OnDisconnection-Methode auf. Infolgedessen wird das Add-In nie entladen, und Outlook 2003 wird nicht beendet.

Wie Visual Studio Tools for Office das Problem beim Beenden behebt

Mit Visual Studio Tools for Office erstellte Outlook 2003-Add-Ins werden auf eine Weise entladen, mit der dieses mögliche Problem vermieden wird. Durch die Visual Studio Tools for Office-Laufzeit wird das Shutdown-Ereignis des Add-Ins ausgelöst, und die Anwendungsdomäne des Add-Ins wird entladen, sofern es über keine Verweise auf Explorer-Objekte oder Inspector-Objekte verfügt, wenn eine der folgenden Situationen vorliegt:

Die Quit-Methode wird aufgerufen.
Das Close-Ereignis von Explorer oder Inspector wird ausgelöst.

Wenn die Anwendungsdomäne entladen wird, werden alle ausstehenden Verweise auf andere Outlook-Objekte bereinigt. Auf diese Weise kann das Add-In von Outlook 2003 beendet und Outlook 2003 selbst beendet werden.