Schreiben von Code in Office-Projektmappen

Artikel
08/10/2011

Einige Aspekte beim Schreiben von Code in Office-Projekten unterscheiden sich von anderen Projekttypen. Viele dieser Unterscheide haben mit der Art zu tun, wie die Office-Objektmodelle im verwalteten Code verfügbar gemacht werden. Andere Unterschiede beziehen sich auf den Entwurf von Office-Projekten.

Betrifft: Die Informationen in diesem Thema betreffen Projekte auf Dokument- und Anwendungsebene für Microsoft Office 2010 und 2007 Microsoft Office System. Weitere Informationen finden Sie unter Verfügbare Funktionen nach Office-Anwendung und Projekttyp.

Verwalteter Code und Office-Programmierung

Die Schlüsseltechnologie, die das Erstellen integrierter Microsoft Office-Projektmappen ermöglicht, ist die Automatisierung. Automatisierung ist Teil der COM-Technologie (Component Object Model). Automatisierung ermöglicht Ihnen die Verwendung von Code zum Erstellen und Steuern von Softwareobjekten, die von einer Anwendung, einer DLL oder einem ActiveX-Steuerelement verfügbar gemacht wird, die bzw. das die entsprechende Programmierschnittstelle unterstützt.

Grundlegendes zu primären Interopassemblys

Viele Funktionen der Microsoft Office-Anwendungen sind für die Automatisierung zugänglich. Sie können verwalteten Code (z. B. Visual Basic oder C#) jedoch nicht direkt zum Automatisieren von Office-Anwendungen verwenden. Zum Automatisieren von Office-Anwendungen mithilfe von verwaltetem Code müssen die primären Office-Interopassemblys verwendet werden. Mithilfe der primären Interopassemblys kann verwalteter Code mit dem COM-basierten Objektmodell der Office-Anwendungen interagieren.

Jede Microsoft Office-Anwendung verfügt über eine primäre Interopassembly (PIA). Wenn Sie in Visual Studio ein Office-Projekt erstellen, wird dem Projekt automatisch ein Verweis auf die entsprechende PIA hinzugefügt. Zum Automatisieren der Funktionen anderer Office-Anwendungen aus dem Projekt muss der entsprechenden primären Interopassembly (PIA) manuell ein Verweis hinzugefügt werden. Weitere Informationen finden Sie unter Verweisen auf Office-Anwendungen durch primäre Interopassemblys.

Verwenden von primären Interopassemblys zur Entwurfs- und Laufzeit

Die Office-PIAs müssen im globalen Assemblycache auf dem Entwicklungscomputer installiert und registriert sein, damit Sie die meisten Entwicklungsaufgaben ausführen können. Weitere Informationen finden Sie unter Konfigurieren eines Computers zum Entwickeln von Office-Lösungen.

Die PIAs müssen auch auf Endbenutzercomputern installiert sein, um Office-Lösungen auszuführen, für die als Zielversion .NET Framework 3.5 festgelegt wurde. Die Office-PIAs sind jedoch auf Endbenutzercomputern nicht erforderlich, um Office-Lösungen auszuführen, für die als Zielversion .NET Framework 4 festgelegt wurde. Weitere Informationen finden Sie unter Entwerfen und Erstellen von Office-Lösungen.

Verwenden von Typen in primären Interopassemblys

Die Office-PIAs enthalten eine Kombination von Typen, die das Objektmodell der Office-Anwendungen und zusätzliche Infrastrukturtypen verfügbar machen, die nicht zur direkten Verwendung im Code vorgesehen sind. Eine Übersicht über die Typen in den Office-PIAs finden Sie unter Overview of Classes and Interfaces in the Office Primary Interop Assemblies.

Da die Typen in den Office-PIAs Typen in den COM-basierten Objektmodellen entsprechen, unterscheidet sich die Art der Verwendung dieser Typen von der anderer verwalteter Typen. Zum Beispiel hängt die Art, wie Sie Methoden mit optionalen Parameter in einer primären Interopassembly von Office aufrufen, von der im Projekt verwendeten Programmiersprache ab. Weitere Informationen finden Sie unter den folgenden Themen:

Programmiermodell von Office-Projekten

Alle Office-Projekte schließen mindestens eine generierte Klasse ein, die den Einstiegspunkt für den Code darstellt. Diese Klassen bieten auch Zugriff auf das Objektmodell der Hostanwendung und Zugriff auf Funktionen wie Aktionsbereiche und benutzerdefinierte Aufgabenbereiche.

Grundlegendes zu den generierten Klassen

In Projekten auf Dokumentebene für Excel und Word ähnelt die generierte Klasse einem Objekt der obersten Ebene im Objektmodell der Anwendung. Die generierte ThisDocument-Klasse in einem Word-Dokumentprojekt stellt beispielsweise dieselben Member wie die Microsoft.Office.Interop.Word.Document-Klasse im Word-Objektmodell bereit. Weitere Informationen zu den generierten Klassen in Projekten auf Dokumentebene finden Sie unter Programmieren von Anpassungen auf Dokumentebene.

In Projekten auf Anwendungsebene wird eine generierte Klasse mit dem Namen ThisAddIn bereitgestellt. Diese Klasse ähnelt keiner Klasse im Objektmodell der Hostanwendung. Diese Klasse stellt stattdessen das Add-In selbst dar, und sie stellt Member bereit, mit denen Sie auf das Objektmodell der Hostanwendung und auf andere Funktionen zugreifen können, die für Add-Ins verfügbar sind. Weitere Informationen finden Sie unter Programmieren von Add-Ins auf Anwendungsebene.

Alle generierten Klassen in Office-Projekte enthalten die Ereignishandler Startup und Shutdown. In der Regel wird diesen Ereignishandlern Code hinzugefügt, um mit dem Schreiben von Code zu beginnen. Um das Add-In zu initialisieren, können Sie dem Startup-Ereignishandler Code hinzufügen. Um vom Add-In verwendete Ressourcen zu bereinigen, können Sie dem Shutdown-Ereignishandler Code hinzufügen. Weitere Informationen finden Sie unter Ereignisse in Office-Projekten.

Zugreifen auf die generierten Klassen zur Laufzeit

Wenn eine Office-Lösung geladen wird, wird jede generierte Klasse im Projekt von Visual Studio Tools for Office-Laufzeit instanziiert. Sie können auf diese Objekte von einem beliebigen Code im Projekt mithilfe der Globals-Klasse zugreifen. Sie können zum Beispiel mit der Globals-Klasse Code in der ThisAddIn-Klasse von einem Ereignishandler einer Menübandschaltfläche in einem Add-In auf Anwendungsebene aufrufen.

Weitere Informationen finden Sie unter Globaler Zugriff auf Objekte in Office-Projekten.