In den ersten beiden Teilen dieser Serie wurden die wichtigsten technischen Grundlagen von Office-Add-Ins vorgestellt. Bei Add-Ins handelt es sich um COM-Objekte, die eine generische Schnittstelle implementieren. Über diese erweitern sie die Funktionalität der Office-Anwendungen. Durch die Verwendung einer allgemein angewendeten Technologie lassen sich Add-Ins von den verschiedenen Office-Anwendungen und einer Reihe anderer Programme wie beispielsweise Visual Studio laden. Zur Erweiterung welcher Programme ein Add-In gedacht ist und wann es geladen wird, wird nur durch Registry Einträge festgelegt.
Zentraler Punkt eines COM-Add-Ins ist die IDTExtensibility2-Klasse. Sie muss für die Einhaltung der Schnittstelle implementiert werden. Sie besitzt neben Funktionen, die zu verschiedenen Zeitpunkten des Ladens und Entladens des Add-Ins aufgerufen werden, eine Reihe von Ereignisroutinen. Diese lassen sich mit einzelnen Objekten verknüpfen und werden beispielsweise dann ausgeführt, wenn ein verknüpftes Objekt gespeichert wird.
Es wurde im zweiten Teil dargestellt, dass auch die neuen .NET-Add-Ins noch auf die COMSchnittstelle zurückgreifen. Die .NET-Klasse, die für die Erweiterung implementiert werden muss, ist mehr oder weniger deckungsgleich mit der notwendigen COM-Klasse IDTExtensibility2. Für die Umsetzung der Funktionsaufrufe zwischen der .NET- und der COM-Umgebung sorgt eine Zwischenschicht, die über einen in Visual Studio .NET enthaltenen Assistenten automatisch erstellt werden kann.
Allerdings ist gerade die Erstellung von Add-Ins für Outlook mit einer Reihe von Problemen behaftet, die es sehr schwierig machen, stabile Software zu entwickeln. Bereits die COM-Schnittstelle von Outlook selbst zeigt einen Designfehler, der bei der Implementierung der Funktionen zur Beendigung des Add-Ins zu einer Endlosschleife führen kann. Die Lösung hierzu wurde in Teil 1 beschrieben.
Auch die Programmierung der Office-Objektbibliothek bereitet einige Schwierigkeit. Office ist ebenfalls ursprünglich ein COM-Objekt, auf das eine .NET-Klassenhierarchie aufgesetzt wurde. Dieser Aufsatz besteht aus den so genannten Primary Interop Assemblies (PIAs). Sie sind in Dateien gespeichert, die entweder zentral im System oder in den Anwendungsverzeichnissen liegen können. Problematisch daran ist, dass es für die verschiedenen Office-Versionen eigene PIAs mit gleichem Namen gibt. Hierdurch kann es zu Versionsproblemen kommen.
Weitere Probleme macht der Übergang zwischen .NET-Add-Ins und der zugrunde liegenden COM-Klasse. Über den Visual Studio-Assistenten erstellte Add-Ins verwenden ein und dasselbe Ladeprogramm. Hierdurch kommt es in der Praxis zu ungewollten Wechselwirkungen zwischen gleichzeitig geladenen Office-Add-Ins.
Um diesem Problem zu begegnen, hat Microsoft das so genannte Shim-Konzept entwickelt. Diese Shims stellen eigenständige Laderoutinen für Add-Ins bereit. Shims lassen sich für bestehende Add-Ins mit Hilfe eines über MSDN verfügbaren Assistenten ohne Softwareunterstützung seitens Microsoft erstellen.
Visual Studio 2005
Vor diesem Hintergrund hat Microsoft im November 2005 Visual Studio 2005 und die Visual Studio Tools for Office 2005 (VSTO 2005) herausgebracht.
Visual Studio 2005 bietet weiterhin einen Assistenten für die Erstellung von generischen Add-In-Projekten an. Dieser entspricht funktional im Wesentlichen dem Assistenten aus Visual Studio .NET 2003. Mit dem Assistenten erstellte Programme werden leider immer noch von einem einzelnen Ladeprogramm gestartet, das heißt, sie besitzen keine eigene Shim. Nur auf die automatische Installation der Office PIAs im Rahmen des mit erstellten Microsoft Installer-Projekts wurde verzichtet. Hier muss der Entwickler bzw. der Endanwender sicherstellen, dass auf den Rechnern die passenden Dateien vorhanden sind. Das lässt sich durch Aktivierung der Option .NET-Programmierunterstützung im Office-Installationsprogramm
für die einzelnen Anwendungen realisieren. Damit diese Option angezeigt wird, muss vorher die .NET Framework Runtime installiert sein. Die PIAs müssen auf jedem Rechner installiert werden, auf dem ein .NET-Add-In ausgeführt werden soll.
Die Visual Studio Tools für Office haben bereits in der letzten Visual Studio-Version die Entwickler-Edition von Office abgelöst. Neu an der gerade erschienenen Version ist, dass sich neben Add-Ins für Word und Excel auch Outlook-Projekte damit erstellen lassen. VSTO ist nicht in der Professional-Version von Visual Studio 2005 enthalten, sondern wird als Zusatzprodukt vertrieben. Die größeren Versionen (Team System) enthalten VSTO bereits. Für Besitzer der Professional-Version mit MSDN-Abonnement ist VSTO als Download im MSDN kostenlos verfügbar. Ersatzweise kann VSTO auch als Einzelprodukt erworben werden. Die Visual Tools machen sich nach der Installation durch neue Projektzweige (Office) für Visual Basic und Visual C# bemerkbar.
VSTO 2005-Outlook-Projekte
Wer allerdings hofft, dass mit der Outlook-Unterstützung in VSTO alles wie von selbst geht, hat sich leider getäuscht. Sinn und Zweck der Aufnahme von Outlook in VSTO war, die bekannten Probleme in einer von Microsoft unterstützten Art und Weise zu lösen, so dass die Entwickler einfach mit dem Programmieren ihrer Lösung anfangen können, ohne sich Sorgen um Shims oder Ähnliches machen zu müssen. Da Outlook von der Art der Anwendung auch weniger dokumentzentriert ist als Word oder Excel, wäre hier die Frage, wie solch ein weiterführender Programm-Assistent aussehen sollte, nicht so einfach zu lösen.
Ein Outlook-Projekt wird in VSTO mit File New/Projekt/Visual C# (Visual Basic)/Office/Outlook Add-In angelegt (Bild 2). Hier ist dann doch noch ein Unterschied zu den regulären Add-In-Projekten zu erkennen. Die erstellte Basisklasse bildet die IDTExtensibility2-Klasse nicht mehr exakt nach. Es wird nur noch eine ThisApplication-Klasse mit den Standardprozeduren Startup und Shutdown erstellt.
Für den Anfang kann jetzt in den beiden Prozeduren durch Einfügen von MessageBox.Show-Befehlen einfach ein Dialog angezeigt werden (Listing 1). Danach kann die Anwendung erstellt werden. Wenn jetzt Outlook gestartet und wieder beendet wird, erscheinen die beiden Dialoge.
Listing 1: Ganz einfaches C#-Add-In mit VSTO
private void ThisApplication_Startup
(object sender, System.EventArgs e)
{
MessageBox.Show("Hallo Welt!");
}
private void ThisApplication_Shutdown
(object sender, System.EventArgs e)
{
MessageBox.Show("Und tschüss!");
}
Wenn das Add-In als Startup-Projekt ausgewählt ist, kann die Anwendung über Visual Studio 2005 im Debug-Modus gestartet werden. Bei Auswahl von StartDebugging wird Outlook automatisch gestartet. Es können dann in Visual Studio 2005 auch Haltepunkte gesetzt werden, um den Programmverlauf näher zu untersuchen.
Auf dem Entwicklungsrechner wird das Add-In automatisch in Outlook integriert und aktiviert. Um das entwickelte Add-In zu deaktivieren, muss der Optionen-Dialog von Outlook geöffnet werden (Extras/Optionen). In der Registerkarte Weitere kann über Erweiterte Optionen/COM-Add-Ins die Add-In-Verwaltung angezeigt werden. Hier lässt sich das neue Add-In deaktivieren oder entfernen werden (Bild 3).
Ereignisprozeduren
Eine der meistbenötigten Aufgaben in Add-Ins und anderen Programmen ist die Programmierung von Ereignisprozeduren. Diese werden immer beim Eintritt eines bestimmten Ereignisses ausgeführt, beispielsweise bei der Ankunft neuer E-Mails.
Ereignisprozeduren sind eine in .NET gut integrierte Funktionalität, die auch von VSTO direkt unterstützt wird. Um eine Prozedur zu erstellen, die beim Ankommen neuer Nachrichten automatisch ausgeführt wird, muss eine Prozedur der Klasse ThisApplication zur passenden Ereignisprozedurliste von Outlook (New- MailEventHandler) hinzugefügt werden. Dies geschieht am einfachsten in der Startup-Prozedur (Listing 2).
Listing 2: Ereignisprozeduren lassen sich einfach
erstellen
private void ThisApplication_Startup
(object sender, System.EventArgs e)
{
this.NewMail +=
new Microsoft.Office.Interop.Outlook.
ApplicationEvents_11_NewMailEventHandler(
ThisApplication_NewMail);
}
void ThisApplication_NewMail()
{
MessageBox.Show("Sie haben neue Nachrichten!");
}
Die möglichen Arten von Ereignisprozeduren lassen sich am einfachsten über die IntelliSense-Funktion von Visual Studio mit [Strg]+[Leer] anzeigen.
Weitere Informationen
Es würde leider den hier zur Verfügung stehenden Rahmen sprengen, die verschiedenen Möglichkeiten des Objektzugriffs hier genauer zu erläutern. Microsoft hat aber auf der MSDN-Website eine Reihe von zusätzlichen Informationen zu VSTO 2005, speziell auch im Bereich Outlook-Entwicklung, für die Allgemeinheit zur Verfügung gestellt. Hier seien die folgenden drei Downloads zu dem Thema genannt. Zum Finden der Dateien rufen Sie am besten http://msdn.microsoft.com auf und geben in der Suchfunktion den Dateinamen ein. Die gefundenen Seiten enthalten in der Regel auch noch Verweise zu weiterführenden Informationen.
-
VSTO-OutlookHandsOnLab.msi: Unterlagen und Programmdateien eines Kurses zum Thema VSTO und Outlook (leider derzeit nur auf Englisch).
-
VSTO-OutlookSamples.msi: Einige Beispielprogramme zum Thema.
-
VSTO-OutlookSnippets.msi: Snippets zur Erweiterung der IntelliSense-Funktion.
Snippets
Das genannte Snippet-Installationspaket enthält verschiedene kurze Codeschnipsel, die bei Bedarf über ein Kontextmenü eingefügt werden können. Das Installationspaket kann in ein beliebiges Verzeichnis entpackt und über die Snippet-Verwaltung (Tools-Menü) hinzugefügt werden. Einfacher ist es, das Unterverzeichnis OfficeDevelopment der Verzeichnisse VB und CS in die jeweiligen Snippet-Verzeichnisse der Visual Studio-Installation zu verschieben (C:\Programme\Microsoft Visual Studio 8\VC#\Snippets\103x und C:\Programme\Microsoft VisualStudio 8\VB\Snippetsx). Auf diese Weise sind die Snippets mit den mitgelieferten Codestücken für die anderen Office-Anwendungen integriert.
Nach der Installation der Snippets kann beispielsweise der notwendige Code für die Erstellung eines Kontakts einfach eingefügt werden. Dazu muss über einen rechten Mausklick an der gewünschten Codestelle das Kontextmenü geöffnet werden. Über die Menüpunkte Insert Snippet/Office Development/Outlook/Create/Create-ContactItem werden die notwendigen Zeilen erzeugt.
Zusammenfassung
Im Rahmen des neu erschienenen Visual Studio 2005 hat Microsoft die Probleme, die bei der Erstellung von Add-Ins entstehen, nicht gelöst. Stattdessen wurde der Weg gewählt, in den zusätzlich verfügbaren Visual Tools für Office eine Outlook-Unterstützung zu integrieren. Das dort enthaltene Projektschema soll die verschiedenen für Outlook-Add-Ins bekannten Probleme lösen. Gleichzeitig wurde die Programmstruktur, die durch den Assistenten erstellt wird, vereinfacht. Sie ist jetzt nicht mehr auf die Struktur der zugrunde liegenden COM-Klasse ausgerichtet, sondern entspricht mehr dem .NET-Konzept.
Mit VSTO 2005 kann zwar ein in der Programmierung unerfahrener Anwender noch immer nicht problemlos eigene Add-Ins erstellen, aber ein nur halbwegs geübter Entwickler kann nun schnell stabile Erweiterungen für Outlook schaffen, ohne sich lange in Systeminterna einarbeiten zu müssen. Durch parallel bereitgestellte Informationen auf der MSDN-Website versucht Microsoft die Entwicklung im Outlook-Bereich jetzt gezielt anzustoßen. Allerdings kann es vor der Entwicklung größerer Projekte eventuell sinnvoll sein, auf die nächste Office-Version zu warten. Diese wird wohl gerade im Bereich Outlook eine Vielzahl von Neuerungen bringen.
Wie geht es weiter?
In den bisherigen Teilen wurde der für Outlook besonders relevante Sicherheitsaspekt noch nicht betrachtet. Die Anwendung setzt dem Automatisierungsdrang schnell durch Sicherheitsabfragen Grenzen. Welche Möglichkeiten es gibt, damit umzugehen, werden wir im letzten Teil der Serie darstellen.