Freigeben über

Schreiben von Code in Office-Lösungen

Es gibt einige Aspekte des Schreibens von Code in Office-Projekten, die sich von anderen Projekttypen in Visual Studio unterscheiden. Viele dieser Unterschiede beziehen sich auf die Art und Weise, wie die Office-Objektmodelle 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 Verfügbare Features nach Office-Anwendung und Projekttyp.

Verwalteter Code und Office-Programmierung

Die Schlüsseltechnologie, die die Erstellung einer integrierten Microsoft Office-Lösung ermöglicht, ist Automatisierung, die Teil der COM-Technologie (Component Object Model) ist. Mithilfe der Automatisierung können Sie Mithilfe von Code Softwareobjekte erstellen und steuern, die von allen Anwendungen, DLL- oder ActiveX-Steuerelementen verfügbar gemacht werden, die die entsprechenden programmgesteuerten Schnittstellen unterstützen.

Grundlegendes zu primären Interop-Assemblies

Microsoft Office-Anwendungen machen einen Großteil ihrer Funktionen für die Automatisierung verfügbar. Sie können verwalteten Code (z. B. Visual Basic oder C#) jedoch nicht direkt zum Automatisieren von Office-Anwendungen verwenden. Um Office-Anwendungen mithilfe von verwaltetem Code zu automatisieren, müssen Sie die primären Interopassemblys (PIAs) von Office verwenden. Die primären Interopassemblys ermöglichen verwaltetem Code die Interaktion mit dem COM-basierten Objektmodell der Office-Anwendungen.

Jede Microsoft Office-Anwendung verfügt über eine PIA. Wenn Sie ein Office-Projekt in Visual Studio erstellen, wird dem Projekt automatisch ein Verweis auf die entsprechende PIA hinzugefügt. Um die Features anderer Office-Anwendungen aus dem Projekt zu automatisieren, müssen Sie manuell einen Verweis auf die entsprechende PIA hinzufügen. Weitere Informationen finden Sie unter Wie man Office-Anwendungen über primäre Interop-Assemblies anvisiert.

Verwenden Sie primäre Interop-Assemblys zur Entwurfs- und Laufzeit

Sie müssen die Office-PIAs installiert und im globalen Assemblycache auf Ihrem Entwicklungscomputer registriert haben, um die meisten Entwicklungsaufgaben auszuführen. 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 Interop-Assemblys

Die Office-PIAs enthalten eine Kombination aus Typen, die das Objektmodell der Office-Anwendungen und zusätzliche Infrastrukturtypen verfügbar machen, die nicht direkt in Ihrem Code verwendet werden sollen. 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 und Weise, wie Sie diese Typen verwenden, häufig von anderen verwalteten Typen. Beispielsweise hängt die Methode zum Aufrufen von Methoden mit optionalen Parametern in einer primären Interopassembly von Office von der programmiersprache ab, die Sie in Ihrem Projekt verwenden. Weitere Informationen finden Sie in folgenden Themen:

Programmmodell von Office-Projekten

Alle Office-Projekte enthalten eine oder mehrere generierte Klassen, die den Einstiegspunkt für Ihren Code bereitstellen. Diese Klassen bieten auch Zugriff auf das Objektmodell der Hostanwendung und zugriff auf Features 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. Beispielsweise stellt die generierte ThisDocument Klasse in einem Word-Dokumentprojekt 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.

Projekte für VSTO-Add-Ins stellen eine generierte Klasse mit dem Namen ThisAddIn bereit. Diese Klasse ähnelt nicht einer 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-Projekten enthalten Startup und Shutdown Ereignishandler. Um mit dem Schreiben von Code zu beginnen, fügen Sie diesen Ereignishandlern in der Regel Code hinzu. Um Ihr VSTO-Add-In zu initialisieren, können Sie dem Startup Ereignishandler Code hinzufügen. Zum Bereinigen von Ressourcen, die von Ihrem VSTO-Add-In verwendet werden, 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 Laufzeitumgebung der Visual Studio Tools für Office jede der generierten Klassen in Ihrem Projekt. Sie können von jedem beliebigen Code in Ihrem Projekt mithilfe der Klasse Globals auf diese Objekte 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

Sie können den Standardnamespace (oder den Stammnamespace in Visual Basic) eines Office-Projekts nicht ändern, nachdem Sie das Projekt erstellt haben. Der Standardnamespace entspricht immer dem Projektnamen, den Sie beim Erstellen des Projekts angegeben haben. Wenn Sie Ihr 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 Host-Item-Klassen in C#-Projekten

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

Um den Namespace der Hostelemente in einem Visual-C#-Office-Projekt zu ändern, verwenden Sie die Eigenschaft Namespace für Hostelement. 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 für Applikationen (VBA) wurden entwickelt, um den Workflow der Anwendungsanpassung zu optimieren. Visual Basic hat einige dieser Entwicklungen geerbt. Visual Basic unterstützt beispielsweise optionale Parameter, was bedeutet, dass Sie weniger Code schreiben können, wenn Sie einige Methoden in den primären Interopassemblys von Microsoft Office aufrufen, als wenn Sie Visual C# verwenden.

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 für die Verwendung mit Microsoft Visual Basic für Applikationen (VBA) entwickelt wurden, können Visual Basic-Entwickler bequem mit den Objekten arbeiten, die von den Microsoft Office-Anwendungen verfügbar gemacht werden. Visual C#-Entwickler können die meisten der gleichen Features wie Visual Basic-Entwickler verwenden, aber es gibt einige Fälle, in denen sie zusätzlichen Code schreiben müssen, um die Office-Objektmodelle zu verwenden. Es gibt auch einige Unterschiede zwischen grundlegenden Programmierfeatures in der Office-Entwicklung und verwaltetem Code, die in Visual Basic und C# geschrieben wurden.

Wichtige Unterschiede zwischen Visual Basic und Visual C#

In der folgenden Tabelle sind die wichtigsten Unterschiede zwischen Visual Basic und Visual C# in der Office-Entwicklung aufgeführt.

Merkmal Description Visual Basic-Unterstützung Visual C#-Unterstützung
Optionale Parameter Viele Microsoft Office-Methoden weisen Parameter auf, die beim Aufrufen der Methode nicht erforderlich sind. 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 als Referenz Optionale Parameter in den meisten primären Interop-Assemblys von Microsoft Office können als Wert übergeben werden. In einigen primären Interop-Assemblys müssen jedoch optionale Parameter, die Referenztypen akzeptieren, per Referenz ü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 ist keine zusätzliche Arbeit erforderlich, um Parameter per Verweis zu übergeben. Der Visual Basic-Compiler übergibt die Parameter bei Bedarf automatisch per Verweis. In den meisten Fällen übergibt der Visual C#-Compiler bei Bedarf automatisch die Parameter durch Verweis. 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äte Bindung Die späte Bindung umfasst die Bestimmung der Eigenschaften von Objekten zur Laufzeit, anstatt Variablen während der Entwurfszeit in den Objekttyp umzuwandeln. Visual Basic führt eine späte Bindung aus, wenn Option Strict deaktiviert ist. Wenn Option Strict aktiviert ist, müssen Sie Objekte explizit konvertieren und Typen im System.Reflection Namespace verwenden, um auf spät gebundene Member zuzugreifen. 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

Die folgende Tabelle zeigt die wichtigsten Unterschiede zwischen der Office-Entwicklung und verwaltetem Code, die in Visual Basic oder Visual C# geschrieben wurden.

Merkmal Description Visual Basic- und Visual C#-Unterstützung
Arrayindizes Die untere Arraygrenze von Sammlungen in Microsoft Office-Anwendungen beginnt 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 anstelle von 0.

Verwandte Inhalte

  • Last updated on