Schreiben von Code in Office-Lösungen

Artikel
10/10/2023

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.

Gilt für: Die Informationen in diesem Thema gelten für Projekte auf Dokumentebene und VSTO-Add-In-Projekte. Siehe features available by Office-App lication and project type.

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 How to: Target Office-App lications through primary interop assemblies.

Verwenden von primären Interopassemblys zur Entwurfszeit 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 Office-PIAs sind auf Endbenutzercomputern nicht erforderlich, um Office-Lösungen auszuführen, die auf .NET Framework 4 oder höher abzielen. 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 Übersicht über Klassen und Schnittstellen in den primären Interopassemblys von Office.

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 in den folgenden Themen:

Programmmodell 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 Document -Klasse im Word-Objektmodell bereit. Weitere Informationen zu den generierten Klassen in Projekten auf Dokumentebene finden Sie unter Programmanpassungen auf Dokumentebene.

In VSTO-Add-In-Projekten wird eine generierte Klasse namens ThisAddInbereitgestellt. Diese Klasse ähnelt keiner Klasse im Objektmodell der Hostanwendung. Stattdessen stellt diese Klasse das VSTO-Add-In selbst dar und stellt Member bereit, die Sie verwenden können, um auf das Objektmodell der Hostanwendung zuzugreifen und auf andere Features zuzugreifen, die für VSTO-Add-Ins verfügbar sind. Weitere Informationen finden Sie unter Programm-VSTO-Add-Ins.

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 VSTO-Add-In zu initialisieren, können Sie dem Startup -Ereignishandler Code hinzufügen. Um vom VSTO-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, instanziiert die Visual Studio-Tools für Office-Laufzeit jede der generierten Klassen in Ihrem Projekt. Sie können auf diese Objekte von einem beliebigen Code im Projekt mithilfe der Globals -Klasse zugreifen. Sie können beispielsweise die Globals Klasse verwenden, um Code in der ThisAddIn Klasse aus einem Ereignishandler einer Menübandschaltfläche in einem VSTO-Add-In aufzurufen.

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

Überlegungen zu Namespaces in Office-Lösungen

Der Standardnamespace (oder Stammnamespace in Visual Basic) eines Office-Projekts kann nach dem Erstellen des Projekts nicht mehr geändert werden. Der Standardnamespace entspricht immer dem Projektnamen, den Sie beim Erstellen des Projekts angegeben haben. Wenn Sie das Projekt umbenennen, ändert sich der Standardnamespace nicht. Weitere Informationen zum Standardnamespace in Projekten finden Sie auf der Anwendungsseite, im Project Designer (C#) und auf der Anwendungsseite, im Project Designer (Visual Basic).

Ändern des Namespace von Hostelementklassen in C#-Projekten

Hostelementklassen (z. B. die ThisAddIn-, ThisWorkbook- oder ThisDocument -Klassen) verfügen über eigene Namespaces in Visual C#-Office-Projekten. Der Namespace für Hostelemente im Projekt entspricht standardmäßig dem Projektnamen, den Sie beim Erstellen des Projekts angegeben haben.

Verwenden Sie die Eigenschaft Namespace für Hostelement , um den Namespace der Hostelemente in einem Visual C#-Office-Projekt zu ändern. Weitere Informationen finden Sie unter "Eigenschaften" in Office-Projekten.

Unterstützte Programmiersprachen in Office-Projekten

Die Office-Projektvorlagen in Visual Studio unterstützen nur die Programmiersprachen Visual Basic und Visual C#. Daher sind diese Projektvorlagen nur unter den Visual Basic - und Visual C# -Knoten des Dialogfelds "Neues Projekt " in Visual Studio verfügbar. Weitere Informationen finden Sie unter How to: Create Office projects in Visual Studio.

Sprachauswahl und Office-Programmierung

Microsoft Office und Visual Basic for Applications (VBA) wurden so entwickelt, dass sie ineinander greifen, um den Workflow der Anwendungsanpassung zu optimieren. Visual Basic hat einige dieser Entwicklungen geerbt. Visual Basic unterstützt z. B. optionale Parameter, d. h. im Vergleich zu Visual C# können Sie beim Aufruf einiger Methoden in den primären Interopassemblys von Microsoft Office weniger Code schreiben.

Programm mit Visual Basic und Visual C# in Office-Lösungen

Sie können Office-Lösungen entweder mit Visual Basic oder Visual C# erstellen. Da die Microsoft Office-Objektmodelle zur Verwendung mit Microsoft Visual Basic for Applications (VBA) entwickelt wurden, können Visual Basic-Entwickler problemlos mit den von den Microsoft Office-Anwendungen verfügbar gemachten Objekten arbeiten. Visual C#-Entwickler können größtenteils die gleichen Funktionen wie Visual Basic-Entwickler nutzen, aber in einigen Fällen müssen sie zusätzlichen Code verfassen, um die Office-Objektmodelle verwenden zu können. Es gibt auch einige Unterschiede zwischen den grundlegenden Programmierfunktionen für die Office-Entwicklung und in Visual Basic und C# geschriebenem verwalteten Code.

Wichtige Unterschiede zwischen Visual Basic und Visual C#

In der folgenden Tabelle werden die wichtigsten Unterschiede zwischen Visual Basic und Visual C# bei der Office-Entwicklung angezeigt.

Funktion	Beschreibung	Visual Basic-Unterstützung	Visual C#-Unterstützung
Optionale Parameter	Viele Microsoft Office-Methoden verfügen über Parameter, die nicht erforderlich sind, wenn Sie die Methode aufrufen. Wenn kein Wert für den Parameter übergeben wird, wird ein Standardwert verwendet.	Visual Basic unterstützt optionale Parameter.	Visual C# unterstützt in den meisten Fällen optionale Parameter. Weitere Informationen finden Sie unter Optionalen Parametern in Office-Lösungen.
Übergeben von Parametern durch einen Verweis	Optionale Parameter können in den meisten der primären Interopassemblys von Microsoft Office als Wert übergeben werden. In manchen primären Interopassemblys müssen optionale Parameter, die Referenztypen akzeptieren, jedoch als Verweis übergeben werden. Weitere Informationen zu Wert- und Referenztypparametern finden Sie unter Übergeben von Argumenten nach Wert und nach Referenz (Visual Basic) (für Visual Basic) und Pass-Parameter (C#-Programmierhandbuch).	Es sind keine weiteren Aufgaben erforderlich, um Parameter als Verweis zu übergeben. Der Visual Basic-Compiler übergibt die Parameter automatisch durch einen Verweis, wenn dies erforderlich ist.	In den meisten Fällen übergibt der Visual C#-Compiler automatisch die Parameter durch einen Verweis, wenn dies erforderlich ist. Weitere Informationen finden Sie unter Optionalen Parametern in Office-Lösungen.
Parametrisierte Eigenschaften	Einige Eigenschaften akzeptieren Parameter und fungieren als schreibgeschützte Funktionen.	Visual Basic unterstützt Eigenschaften, die Parameter akzeptieren.	Visual C# unterstützt Eigenschaften, die Parameter akzeptieren.
Spätes Binden	Bei der späten Bindung werden die Eigenschaften von Objekten zur Laufzeit bestimmt, statt Variablen zur Entwurfszeit in den Objekttyp umzuwandeln.	Visual Basic führt späte Bindungen aus, wenn Option Strict deaktiviert ist. Wenn Option Strict aktiviert ist, müssen Objekte explizit konvertiert und Typen im System.Reflection -Namespace verwendet werden, um auf spät gebundene Member zugreifen zu können. Weitere Informationen finden Sie unter späte Bindung in Office-Lösungen.	Visual C# führt späte Bindung in Projekten aus, die auf .NET Framework 4 abzielen. Weitere Informationen finden Sie unter späte Bindung in Office-Lösungen.

Wichtige Unterschiede zwischen der Office-Entwicklung und verwaltetem Code

In der folgenden Tabelle werden die wichtigsten Unterschiede zwischen der Office-Entwicklung und verwaltetem Code angezeigt, der mit Visual Basic und Visual C# geschrieben wurde.

Funktion	Beschreibung	Visual Basic- und Visual C#-Unterstützung
Arrayindizes	Die unteren Arraygrenzen der Auflistungen in Microsoft Office-Anwendungen beginnen mit 1. Visual Basic und Visual C# verwenden 0-basierte Arrays. Weitere Informationen finden Sie unter Arrays (C#-Programmierhandbuch) und Arrays in Visual Basic.	Um auf das erste Element einer Auflistung im Objektmodell einer Microsoft Office-Anwendung zuzugreifen, verwenden Sie den Index 1 statt 0.