Laden...
FAQ

[FAQ] Office (Word, Excel, Outlook, ...) in eigenen Anwendungen verwenden

Erstellt von Rainbird vor 17 Jahren Letzter Beitrag vor 17 Jahren 84.147 Views
Rainbird Themenstarter:in
3.728 Beiträge seit 2005
vor 17 Jahren
[FAQ] Office (Word, Excel, Outlook, ...) in eigenen Anwendungen verwenden

Zuerst stellt sich die Frage, was genau mit Office gemacht werden soll? Dieser FAQ-Beitrag gibt Antworten auf folgende Fragen:

Wie funktioniert Office Automatisierung mit C#?
Wie kann ich verschiedene Office-Versionen unterstüzen?
Wie kann ich auf Outlook bzw. Exchange Server zugreifen?
Wie kann ich schnell auf Access, Excel und Outlook Daten zugreifen?
Wie kann ich Office Add-Ins mit C# erstellen?
Wie kann ich die neuen XML Funktionen von Office 2003/2007 nutzen?
Wie kann ich Office als Plattform für meine .NET Anwendungen verwenden (VSTO)?
Wie kann ich in Office-Anwendungen Webservices aufrufen?

Wie funktioniert Office Automatisierung mit C#?

Automatisierung von Office heißt fernsteuern bestimmter Office Anwendungen von Ihrer eigenen Anwendung aus. Generell verfügen die einzelnen Office Anwendungen wie z.B. Word oder Excel über COM-Schnittstellen. COM steht für Component Object Model und ist eine Microsoft-Technologie um Software-Komponenten zu erstellen. Entwickler, die mit Office arbeiten möchten, sollten die grundlegenden Konzepte von COM unbedingt kennen.

Office-Applikationen wie Excel, Word & Co. sind Anwendungen, die dafür entwickelt wurden, auf einem Client zu laufen und von einem Menschen über die GUI bedient zu werden. Deshalb sollte COM Automatisierung niemals auf einem Server (z.B. serverseitig in einer Webanwendung) verwendet werden! Dafür gibts ab Office 2003 die XML-Formate (Siehe weiter unten). Ein Beispiel für Excel-XML-Export ohne Excel gibts hier:
Excel-Export ohne Excel (Snippet)

Informationen über die Verwendung von COM-Komponenten in .NET Applikation finden sich in folgendem MSDN-Artikel:

C# Tipps - Interoperabilität mit nicht verwaltetem Code

Ab der Office Version 2002 stehen für die .NET Integration so genannte Primary Interop Assemblies (PIA) zur Verfügung. Diese legen die Office Programmierschnittstellen in einer, für .NET Entwickler, leichter zu handhabenden Art und Weise offen. Zu beachten ist, dass die Primary Interop Assemblies bei Verwendung nicht nur auf dem Entwickler-PC benötigt werden, sondern auch mit der .NET Applikation mit an die Clients verteilt werden müssen.
Für ältere Office Versionen gibt es keine Interop Assemblies. Trotzdem kann Office 2000 auch in eigene C# Anwendungen eingebunden werden. In diesem Fall greifen die Standard Tools für COM Interoperabilität im .NET Framework und in Visual Studio. Mit Office 95/97 gibt es erfahrungsgemäß Probleme im Zusammenhang mit .NET. Projekte auf einer Office-Version aufzubauen, deren Support aufgekündigt ist und die 10 Jahre oder älter ist, macht eigentlich keinen Sinn. Deshalb wird dieser FAQ-Beitrag nicht weiter auf diese „alten“ Office Versionen eingehen. Benutzer von office 95/97 sollten schnellst möglich auf eine moderne Version von Office umsteigen, wenn es mit der Automatisierung aus .NET Anwendungen heraus was werden soll.

Hier gibt’s die Primary Interop Assemblies für Office XP (2002):

Microsoft Download Center: Office XP PIAs

Hier gibt’s die Primary Interop Assemblies für Office 2003:

Microsoft Download Center: Office 2003 Update: Redistributable Primary Interop Assemblies

Hier gibt´s die Primary Interop Assemblies für Office 2007:

Microsoft Download Center: 2007 Microsoft Office System Update: Redistributable Primary Interop Assemblies
Weitere Infos zu den 2007er PIAs: Office Primary Interop Assemblies

Um ältere (Office Xp/2003) Automatisierungsanwendungen an die neuen Interop Assemblies zu binden, kann man Assembly Binding Redirection einsetzen.

Für die Automatisierung müssen die Interop Assemblies der gewünschten Office Anwendung (z.B. Word) als Verweise zum C#-Projekt hinzugefügt werden. Die Programmierschnittstellen von Office sind objektorientiert aufgebaut. Es gibt also für die verschiedenen Bestandteile einer Office Anwendung entsprechende Klassen. Bei Word gibt es z.B. eine Document-Klasse, die ein einzelnes Word-Dokument repräsentiert. Das Selection gibt dem Entwickler zugriff auf den markierten Bereich im Dokument. Und so weiter. Folgender Artikel demonstriert die Automatisierung an Beispielen mit Excel und Word:

Programmieren von Microsoft Word 2002 und Excel 2002 mit Microsoft Visual C#

Viele Code-Beispiele für Office sind in Visual Basic oder Visual Basic.NET geschrieben, da Visual Basic im Office Umfeld sehr verbreitet und beliebt ist. Deshalb sollte man als C# Entwickler zumindest in der Lage sein, Visual Basic Quellcode zu lesen und zu verstehen. Folgender Artikel veranschaulicht die kleinen Unterschiede der Programmiersprachen:

Zehn Codeversionen für VBA, Visual Basic .NET und C#

In den Beispielen funktioniert natürlich immer alles, aber in der eigenen Anwendung sieht es manchmal anders aus. Gründe dafür sind die Komplexität einer Anwendung wie Excel, Sicherheitseinstellungen und Benutzerrechte, dass COM und .NET verschiedene Typsysteme haben und vor allem die grundlegend verschiedene Speicherverwaltung von COM und .NET. COM arbeitet mit Verweiszählung. Fällt der letzte Verweis auf ein Objekt im Speicher, wird dieses zerstört. Bei .NET kommt dagegen ein Garbage Collector (zu deutsch Müllsammler) zum Einsatz, der nicht mehr verwendete Objekte automatisch erkennt und zerstört. Folgender Artikel kann besonders bei Problemen mit der Office Automatisierung sehr hilfreich sein:

Behandlung komplexer COM-Objekte mit Interop-Assemblys

Wie kann ich verschiedene Office-Versionen unterstüzen?

Das geht am besten über Reflection. Reflection ermöglicht Späte Bindung in C#. Späte Bindung heißt, dass man mit Typen arbieten kann, die zur Kompilierzeit nicht bekannt sind. Hier ist ein Beispiel wie man Reflection zur Automatisierung von verschiedenen Office-Versionen (Version 2000 oder höher) einsetzen kann: Allgemeiner COM-Wrapper für Späte Bindung.

Wie kann ich auf Outlook bzw. Exchange Server zugreifen?

Outlook hat genau wie Excel oder Word ein COM-Objektmodell. Dieses eignet sich gut, um Outlook fernzusteuern. Allerdings gibt es einige Beschränkungen. Vor allem eine nervige Sicherheitswarnung, beim versenden vom E-Mails, die man nicht abschalten kann. Deshalb ist das Outlook-Objektmodell nicht immer die Erste Wahl. Um die Beschränkungen zu umgehen, sollte man sich deshalb auf jeden Fall Redemption ansehen: http://www.dimastr.com/redemption/. Das ist eine COM-Bibliothek, die Extended MAPI kapselt. Mit Redeption RDO kann man auch direkt auf einen Exchange Server zugreifen. Das ist wesentlich komfortabler als WebDAV und CDO 1.21 ist sowieso nicht mit .NET verträglich.
Der Exchange Server 2007 hat auch eine Webservice-API, die allen anderen Varianten vorzuziehen ist: MSXFAQ.de: WebServices.
Wer noch ältere Versionen des Exchange Server betreibt, ist mit Redemption sehr gut beraten.

Wie kann ich schnell auf Access, Excel und Outlook Daten zugreifen?

Access, Excel und Outlook können über einen OLEDB Datenprovider angesprochen werden. Bei Access ist dieses Verfahren bekannt und weit verbreitet. Dass es auch mit Excel und Outlook funktioniert, wissen aber manche nicht. Der Datenzugriff über OLEDB ist sehr viel schneller, als die Automatisierung über COM-Schnittstellen (kann locker 50 Mal so schnell sein).
In C# werden Datenzugriffe über eine OLEDB-Verbindung mit ADO.NET gemacht. Detaillierte Informationen zu ADO.NET lassen sich leicht in der Forumssuche und in der MSDN Library finden. Folgfender Artikel beschreibt den Datenzugriff auf Access und Excel ausführlich:

Von .NET-Anwendungen auf Microsoft Office-Daten zugreifen

Folgende Artikel zeigen, wie es mit Outlook funktioniert:

Der OLEDB-Zugriff auf Outlook ist nicht unbedingt eine robuste Technologie und deshalb mit Vorsicht zu genießen! Siehe vorherigen Abschnitt für Alternativen.

Outlook: Via OLEDB schnell auf Outlook-Daten zugreifen
Accessing Microsoft Exchange and Outlook Data Using Visual Basic
KB3B275262: How to retrieve Exchange and Outlook data with the Jet 4.0 OLE DB provider in Access 2000
The Jet 4.0 Exchange/Outlook IISAM

Wie kann ich Office Add-Ins mit C# erstellen?

Die Funktionalität von Office Anwendungen kann durch so genannte Add-Ins erweitert werden. Ein Add-In ist eine Komponente, die eine bestimmte Schnittstelle implementiert und beim start einer Office Anwendung automatisch geladen wird. Add-Ins sind sehr mächtig und können fast alle Merkmale von Office beeinflussen. Zum Beispiel kann ein Add-In neue Menüs hinzufügen, ein bestimmtes Kontextmenü erweitern oder eigene Dialoge und Assistenten einblenden. Für die Add-In Erstellung gibt es in Visual Studio spezielle Projektvorlagen.

Der komfortabelste Weg, Office-Add-Ins zu erstellen ist mit VSTO (Visual Studio Tools for Office). (Siehe dazu bitte letzter Abschnitt!

Da die Add-In Tools von VSTO mittlerweile kostenlos sind, sollte man in zusammenhang mit .NET nur noch VSTO Add-Ins entwickeln. VSTO Add-Ins sind wesentlich robuster, da sie isoliert voneinander in verschiedenen Anwendungsdomänen ausgeführt werden.

Folgende Artikel beschreiben den Vorgang der Add-In Erstellung sehr ausführlich:

KB302901: Erstellen eines Office COM-Add-Ins mit Visual C# .NET
Entwickeln von .NET-Smart Clients für Microsoft Office XP (Teil 1)
Entwickeln von .NET-Smart Clients für Microsoft Office XP (Teil 2)
Entwickeln von .NET-Smart Clients für Microsoft Office XP (Teil 3)
Entwickeln von Lösungen mit Microsoft Outlook 2002

Besonders interessant für AddIn-Entwickler sind benutzerdefinierte Aufgabenbereiche in Office 2007:

Erstellen von benutzerdefinierten Aufgabenbereichen in Office (2007)

Wenn Add-Ins, die mit Visual Studio 2005 erstellt wurden, in Office nicht starten wollen, muss möglicherweise das folgende Hotfix auf dem Entwickler-PC eingespielt werden: KB908002: FIX: Add-ins, smart documents, or smart tags that you create by using Microsoft Visual Studio 2005 do not run in Office

Ansonsten ist folgender MSDN-Artikel sehr hilfreich, wenn das selbst entwickelte Add-In einfach nicht laufen will, oder während der Laufzeit bizarre Resultate liefert: Debugging in Application-Level Projects

Wie kann ich die neuen XML Funktionen von Office 2003/2007 nutzen?

In den Office Versionen 2003 und 2007 gibt es für Entwickler neue Möglichkeiten durch die neuen XML Funktionen der Office Anwendungen. Mittels XML kann man z.B. auf einem Server ein komplettes Word-Dokument erzeugen, ohne dass Word auf diesem Computer installiert ist (Hier gibts die benötigten Schemas und die Dokumentation dazu: Microsoft Download Center: Office 2003: XML Reference Schemas).
Für das Erzeugen von Excel-Dokumenten mit XML gibts es eine freie .NET-Komponente, die einen Großteil der Komplexität von SpreadsheetML (So heißt das XML-Format von Excel) kapselt: CarlosAg Excel Xml Writer Library
Hier ein Beispiel, wie man Excel-Dokumente mit einem einfachen XmlTextWriter erzeugt: Excel-Export ohne Excel (Snippet)

Office Dokumente können mit XML-Schemas versehen, damit der Dokumentinhalt automatisch weiterverarbeitet werden kann. Mit InfoPath als neuster Office Anwendung können XML Formulare erzeugt und die Eingaben per SOAP-Webservices an Backend-System geschickt werden. XML ist ein weltweit anerkannter Standard, um Informationen zu beschreiben. Einige Probleme lassen sich mit XML-Technologie viel einfacher und eleganter Lösen, als mit tonnenweise Office-Automatisierungscode. In der MSDN Library wurde dazu folgende Artikel veröffentlicht:

Office 2003 und XML
Microsoft Office System: Überblick über Entwicklertechnologien

Ab Office 2007 können die sogenannte Open XML Formate als Dateiformate für die einzelnen Office-Anwendungen verwendet werden. Infos dazu finden sich in folgendem MSDN-Artikel:
Einführung in die Microsoft Office (2007) Open XML-Dateiformate

Wie kann ich Office als Plattform für meine .NET Anwendungen verwenden (VSTO)?

Vor Office 2003 wurden Office basierte Applikationen mit Visual Basic for Applications (kurz VBA) geschrieben. VBA ist eine, für Customizing von Anwendungen angepasste Version von Visual Basic. Mit VBA war es möglich, Anwendungscode direkt in verschiedenen Office Anwendungen zu schreiben (Durch drücken von [Alt] + [F11] in einer Office Applikation, wird der Visual Basic Editor geöffnet).
Für die Erstellung von Office 2003/2007 basierten Anwendungen muss man seine gewohnte C# Welt nicht mehr verlassen. Die Visual Studio Tools for Office (kurz VSTO) bringen Office .NET bei. So könnte z.B. eine in C# geschriebene Angebotsverwaltung direkt aus Excel genutzt werden. Vorteil dabei: Die Anwender werden gerne damit arbeiten, weil sie Excel kennen und sie in einer vertrauten Oberfläche verbleiben können.

VSTO ermöglicht die Entwicklung von Dokumentbezogenen Anwendungen und von Applikationsbezogenen Anwendungen. Erstere sollen die Aufgabe von VBA-Makros übernehmen. Dabei werden Dokumente (z.B. eine Excel-Tabelle) mit .NET Assemblies verknüpft, die automatisch von Office mit dem Dokument geladen werden. Die Assemblies sind dabei nicht, wie VBA-Makros, in die Office-Dokumente eingebettet, sondern werden von der VSTO-Laufzeitumgebung als DLLs geladen. Die Assemblies mit den eigenen Erweiterungen können z.B. auf einem Server liegen.
Bei Applikationsbezogenen VSTO-Anwendungen handelt es sich um die auch schon früher bekannten Office-Add-Ins. Vorteil der Add-In-Programmierung mit VSTO ist die bessere Unterstützung in Visual Studio. Auch um COM-Interop muss man sich bei VSTO-Add-Ins nicht mehr viel kümmern. Das erledigt die VSTO Laufzeitumgebung.

VSTO ist ein kostenpflichtiges Zusatzprodukt und nicht in Visual Studio enthalten. Die aktulle Version VSTO 2005 Second Edition kann zwar kostenlos heruntergeladen und installiert werden, gibt aber nur für Besitzer des Vollprodukts "Visual Studio Tool for Office 2005" alle Features frei. Benutzer eines einfachen Visual Studio 2005 Professional oder besser kommen aber in den Genuß der VSTO-Add-In-Features (Also des anwendungsbezogenen Teils). Dies äußert sich in neuen Office-Add-In-Vorlagen in Visual Studio.

Hier gibts die Second Edition für Office 2003/2007 zum runterladen:
Microsoft Download Center: Microsoft Visual Studio 2005 Tools for the 2007 Microsoft Office System

Es ist nicht immer ganz einfach, VSTO Add-Ins zum laufen zu bekommen. VSTO ist recht empfindlich was die Sicherheitseinstellungen und die Prerequisites betrifft. Deshalb hat Microsoft einen kostenlosen Troubleshooter für Probleme mit VSTO Add-Ins veröffentlicht: Rainbirds Blog: Diagnosewerkzeug für VSTO Deployment-Probleme

Weitere Informationen über VSTO gibts hier:
Visual Studio 2005 Tools for the Microsoft Office System
Zugreifen auf Webdienste mit Excel über Visual Studio-Tools für Microsoft Office System
VSTO 2005: Excel 2003-Lösung mit dynamischen Steuerelementen und Ansichten
Rechnungsstellung in Excel mit Visual Studio-Tools für Office 2005

Wie kann ich in Office-Anwendungen Webservices aufrufen?

Als .NET-Entwickler führt der Weg über VSTO. Innerhalb von VSTO-Projekten können alle Features des .NET Frameworks verwendet werden. Also auch Webservices. Die Handhabung ist nicht anders als in einer Konsolenanwendung oder einer Windows.Forms-Anwendung.

Auch VBA-Entwickler können ganz leicht in den Genuß von direkten Webservice-Aufrufen kommen. Mit dem Microsoft SOAP Toolkit 3.0, welches als COM-Verweis in VBA-Projekte eingebunden werden kann, können SOAP-Webservices auch im guten alten VBA ohne große Mühe aufgerufen werden. Leider ist der Support für das SOAP Toolkit bereits eingestellt! Neue Office-Projekte sollte man deshalb gar nicht erst in VBA entwicklen, sondern gleicht mit .NET Technologie. Für alle die ihre Millionen Zeilen an VBA-Makros nicht wegwerfen wollen/können und unkompliziert Webservices konsumieren möchten, gibts das SOAP Toolkit 3.0 hier noch kostenlos zum runterladen: Microsoft Download Center: SOAP Toolkit 3.0