Schreiben von Code in Office-Projektmappen

Artikel
03/22/2013

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 auf Anwendungsebene für Office 2013 und Office 2010. 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 Office-PIAs sind nicht auf Endbenutzercomputern erforderlich, um Office-Lösungen auszuführen, die .NET Framework 4 oder .NET Framework 4.5 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 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 hierzu 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 hierzu 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 für 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.

Namespace-Überlegungen in Office-Projektmappen

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 unter Seite "Anwendung", Projekt-Designer (C#) und Seite "Anwendung", Projekt-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 Knoten Visual Basic und Visual C# des Dialogfelds Neues Projekt in Visual Studio verfügbar.Weitere Informationen finden Sie unter Gewusst wie: Erstellen von Office-Projekten 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.

Programmierung mit Visual Basic VS . Visual C# in Office-Projektmappen

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.In Visual Studio 2012 können Visual C#-Entwickler größtenteils die gleichen Funktionen wie auch Visual Basic-Entwickler nutzen, doch 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.

Wesentliche Unterschiede zwischen Visual Basic und Visual Basic/C# 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 Optionale Parameter 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 über Wert- und Referenztypparameter finden Sie unter Übergeben von Argumenten als Wert und als Verweis (Visual Basic) (für Visual Basic) und Übergeben von Parametern (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 Optionale Parameter 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 Bindungen in Projekten aus, für die als Zielversion .NET Framework 4 festgelegt wurde.Weitere Informationen finden Sie unter Späte Bindung in Office-Lösungen.

Hauptunterschiede zwischen 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 untere Arraygrenze 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 unter 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.