Praktisches Wissen über die Verwendung von Office als Entwicklungsplattform

Unternehmensanwendungen

Veröffentlicht: 11. Sep 2006
Von Andrew Whitechapel und John Peltonen

Microsoft Office 2007 bietet zweifellos die Grundlage für einige recht komplexe benutzerdefinierte Lösungen, und Tausende solcher Lösungen werden heutzutage problemlos in Office ausgeführt. Kann Office aber auch als eine robuste Entwicklungsplattform dienen? Bietet Office die erforderlichen Bausteine für das Erstellen ganz neuer Anwendungen?

Office wurde und wird gewöhnlich als ein Paket eigenständiger clientseitiger Anwendungen — Word, Excel® und Outlook® — angesehen, die einen umfassenden Satz von Funktionen bieten sollen. Da diese Funktionen für jede Anwendung für eine bestimmte Reihe von Aufgaben für Benutzer ausgelegt war, gab es nur minimale explizite Interoperabilität zwischen den verschiedenen Anwendungen. Office hat sich aber nun mehr zu einem System aus Anwendungen und Technologien entwickelt, die Dienste für sowohl Clients als auch Server bieten und Microsoft InfoPath®, SharePoint® Services, Content Management Server und Exchange Server umfassen.

Word, Excel, Outlook und all die anderen Office-Anwendungen wurden absichtlich so entwickelt, dass die meisten Funktionen als COM-Server für eine externe Verwendung offen gelegt sind. Dies macht deutlich, dass die Architekten von Office ganz klar benutzerdefinierte Lösungen im Sinn hatten. Das Ergebnis ist, dass Sie einfach Lösungen erstellen können, die sich nahtlos mit einer oder mehreren Office-Anwendungen verknüpfen. Zudem gehen mit einer Office-Komponente wie SharePoint auch Portaldienste, Teamdienste, Workflowfunktionen und Content Management einher. Man könnte behaupten, dass SharePoint allein schon eine ziemlich umfassende Entwicklungsplattform ist.

Eine echte Entwicklungsplattform muss einige grundlegende Anforderungen erfüllen. Darüber, wie diese Anforderungen aussehen, gibt es vermutlich allgemeine Vorstellungen, zumindest sollten sie jedoch generische, grundlegende Unternehmensdienste, Erweiterungspunkte, mit denen sich Lösungen mit den generischen Diensten verknüpfen können, sowie ein konsistentes Toolset für den Aufbau auf der Basis der Grunddienste umfassen. Sie benötigen zudem ein Minimum von Attributen ohne Funktion, mit denen die funktionalen Dienste für die Erstellung realistischer Unternehmenslösungen genutzt werden können (siehe Abbildung 1). Office erfüllt nicht nur diese Anforderungen, sondern bietet darüber hinaus zwei weitere Vorteile: Entwickler, die schon mit Windows® gearbeitet haben, weisen bereits das Wissen und die Erfahrung auf, die sie für die Nutzung der Office-Plattform benötigen, und Microsoft hat eine Anzahl von Tools veröffentlicht, die Entwicklern beim Erstellen neuer Anwendungen auf der Grundlage der Plattform helfen.

Abbildung 1: Plattformcharakteristiken
Abbildung 1: Plattformcharakteristiken

Auf dieser Seite

Grundlagen der Office-Plattform

Sie können ein Schema der Anforderungen einer Entwicklungsplattform an Office aufstellen und anfangen, es mit einigen der spezifischen Funktionen auszufüllen, wie in Abbildung 2 dargestellt. Als eine Entwicklungsplattform muss Office eine Reihe grundlegender Anforderungen erfüllen. Dazu gehören Zuverlässigkeit, Skalierbarkeit, Sicherheit, Bereitstellung und Aktualisierung, Wiederverwendbarkeit durch Aufteilung in Komponenten, ein konsistentes Objektmodell und Versionskompatibilität. Im Folgenden werden diese Anforderungen erläutert, und Sie erfahren, wie Office 2007 sie erfüllt.

Abbildung 2: Eine Darstellung der Office-Entwicklungsplattform
Abbildung 2: Eine Darstellung der Office-Entwicklungsplattform

Office bietet Zuverlässigkeit hauptsächlich auf drei Arten. Erstens sind die Office-Anwendungen selbst mit einem hohen Grad an Robustheit entwickelt. Zweitens umfasst Office eine Reihe von Maßnahmen zum Selbstschutz vor bösartige Anpassungen. Wenn zum Beispiel ein Add-In seine Hostanwendung zum Absturz bringt, erkennt Office dies, und setzt das Add-In auf die schwarze Liste, damit es in Zukunft nicht mehr geladen wird. Die meisten Ausnahmefehler, die von einer Office-Anpassung oder einem Add-In ausgelöst werden, werden automatisch gehandhabt, um eine Destabilisierung des Hosts zu vermeiden. In einigen Fällen zeigt die Anwendung ein Dialogfeld mit einer entsprechenden Fehlermeldung an, damit der Benutzer weiß, dass Office richtig funktioniert, das Add-In sich allerdings in einem nicht definierten Zustand befindet. Drittens wurde der Microsoft® Office SharePoint Server (MOSS) 2007 entsprechend den gleichen anspruchsvollen Standards wie andere Microsoft-Serversoftware entwickelt, und Dienste, die auf SharePoint basieren, weisen denselben hohen Grad an Zuverlässigkeit auf.

Skalierbarkeit und Leistung haben zwei Dimensionen, die Clientseite und die Serverseite. Auf dem Client setzt jede Office-Anwendung bestimmte Begrenzungen wie z. B. die Höchstzahl von Zeilen und Spalten in einem Excel-Arbeitsblatt. Die Skalierbarkeit wird so vorhersehbar: Sie können einfach keine benutzerdefinierte Lösung erstellen, die diese Grenzen überschreitet. Es ist allerdings möglich, Lösungen bereitzustellen, die praktische Einschränkungen in einem Kontext überschreiten, in dem keine harten Grenzen definiert sind. So gibt es beispielsweise keine spezifischen Einschränkungen für die Anzahl von Add-Ins, die Sie für eine einzelne Anwendung registrieren können, aber es bestehen durchaus praktische Grenzen. Denken Sie nur an die Leistungseinbußen, die beim Start von Excel entstehen würden, wenn die Anwendung 10.000 Add-Ins laden müsste. Dies ist ein gutes Beispiel für die Art von Entscheidung, die eine Entwicklungsplattform Consumern nicht abnehmen sollte.

Aus demselben Grund, aus dem Sie nicht 10.000 Add-Ins laden würden, sollten Sie auch Office-Clientanwendungen auf dem Server nicht automatisieren: Es ist einfach nicht praktisch, obwohl es technisch durchaus möglich ist. Office 2007 stellt allerdings die Excel-Berechnungs-Engine und andere Funktionen mit SharePoint- und Excel-Diensten auf dem Server zur Verfügung (siehe Abbildung 3). Windows SharePoint Services (WSS) 3.0 bietet integrierte Workflowunterstützung, systemeigene Unterstützung für ASP.NET 2.0 sowie Unterstützung für Blogs, Wikis und RSS. MOSS 2007 baut auf dieser Grundlage auf und führt Content Management, Business Intelligence (BI), webbasierte Tabellenfunktionen für Excel-Dienste, Unterstützung für InfoPath-Formulare, auf Dokument und Listen konzentrierte Workflows sowie Verbesserungen bei der Suche ein. Zudem ermöglichen die MOSS BDC-Dienste (Business Data Catalog) den Abruf von Informationen von Back-End-Systemen, wie z. B. Anwendungen für die Verwaltung von Kundenbeziehungen (Customer Relationship Management, CRM) und die Unternehmensressourcenplanung (Enterprise Resource Planning, ERP). (Weitere Informationen über MOSS 2007 finden Sie in Ted Pattisons Artikel in dieser Ausgabe.)

Abbildung 3: Komponenten der Excel-Dienste
Abbildung 3: Komponenten der Excel-Dienste

In der Vergangenheit war die Sicherheit von Office etwas schwer für Benutzer zu verstehen und für Administratoren zu verwalten. In Office 2007 wurde das Sicherheitsmodell völlig umgearbeitet und ist jetzt ohne Einbußen in der Leistungsfähigkeit für Benutzer leichter zu verstehen, transparenter und einfacher zu verwalten. Visual Studio-Tools für Office hat schon immer ein strengeres Sicherheitsmodell verwendet, aber die Stärke dieser Sicherheit machte die Verwaltung des Modells auch schwieriger.

Bei herkömmlichen Office-basierten Lösungen wurde Office entweder extern automatisiert, Add-Ins irgendeiner Art (COM-Add-Ins, Smarttags oder Echtzeitdaten) wurden registriert oder dokumentbasierte Lösungen wurden bereitgestellt, bei denen die Automatisierung während des Vorgangs durch in das Dokument eingebettetes Visual Basic für Applikationen (Visual Basic for Applications, VBA) vorgenommen wurde. Die Bereitstellung und Aktualisierung für externe Automatisierungslösungen ist recht unkompliziert: Eine Lösung, die in der Windows-Registrierung registriert werden muss, hat typischerweise gut definierte Bereitstellungsprozesse, und zur Aktualisierung muss nur eine neue Version installiert werden.

Die Bereitstellung ist nur bei dokumentbasierten Lösungen ein Problem. Die meisten Dokumente sind nutzlos, wenn sie nicht vom Benutzer geändert werden können, aber eine Änderung von Dokumenten bringt die Möglichkeit mit sich, dass auch das VBA geändert wird. Auch wenn Sie das verhindern, kann (und typischerweise wird) sich der VBA-Code abhängig von den Daten im Dokument anders verhalten. So können Sie schnell mehrere Versionen der Lösung erhalten, deren Verfolgung zu einem Albtraum wird. VBA eignet sich nicht als Steuerelement, und die Überwachung und die Einhaltung gesetzlicher Bestimmungen wird nahezu unmöglich.

Visual Studio-Tools für Office berücksichtigen diese Probleme, indem sie ein äußerst flexibles Bereitstellungsmodell bieten. Lösungen von Visual Studio-Tools für Office — sowohl Add-Ins auf Anwendungs- als auch Anpassungen auf Dokumentebene — ermöglichen es, dass der Code lokal oder remote bereitgestellt wird, und beide Lösungsarten beinhalten automatische Aktualisierungen. Bei einer Remote-Bereitstellung wird die Verwaltungsaufgabe vereinfacht, da sich die Assemblys auf einem Server befinden und nicht auf den Benutzerdesktops verteilt sind. Wenn Office eine Lösung lädt, führen die Visual Studio-Tools für Office-Laufzeit eine Überprüfung auf eine aktualisierte Version durch und laden diese ggf. automatisch auf den lokalen Computer herunter.

Das Office-Objektmodell

Wie an früherer Stelle erwähnt, legen Office-Anwendungen COM-Schnittstellen offen. So können Sie sich zum Beispiel auf das Word-Dokumentobjekt konzentrieren und es unabhängig logisch instanziieren, aber in der Praxis wird der Word-Prozess ausgeführt, um dieses Objekt bereitzustellen. Wenn Sie allerdings wirklich eine Entwicklungsplattform wünschen, dann wünschen Sie auch, dass der Rest der Plattform verfügbar ist, auch wenn Sie vielleicht in einem speziellen Szenario nur eine Komponente verwenden. Diese Komponente soll andere benötigte Plattformdienste verwenden können, ohne dass Sie diese Dienste selbst manuell instanziieren müssen.

Was ist der richtige Platz für eine Aufteilung in Komponenten in einem Office-Lösungskontext? Viele Kunden erstellen ihre eigenen domänenspezifischen, wieder verwendbaren Komponenten und strukturieren sie schichtweise mit Office als Grundlage. So verwendet zum Beispiel eine Komponente, die für eine Emissionsgeschäftsfunktion spezifisch ist, ggf. die Excel-Berechnungs-Engine. Die lösungsseitige Schnittstelle dieser Komponente ist domänenspezifisch, während die plattformseitige Schnittstelle Excel-spezifisch ist. Mit dieser Abstraktion kann die Komponente mit mehreren Versionen von Excel funktionieren — eine typische Anforderung von Kunden.

Wahlweise könnten Sie auch eine generische, wieder verwendbare Komponente erstellen, die hostanwendungsneutral ist. Stellen Sie sich beispielsweise ein Benutzersteuerelement vor, das Webdienste zum Anzeigen von Daten in einem benutzerdefinierten Aufgabenbereich verwendet. Dasselbe Steuerelement könnte in mehreren Office-Anwendungen wieder verwendet werden.

Office-Anwendungen wurden im Lauf der Zeit weiterentwickelt und weisen ganz unterschiedliche Funktionssätze auf; daher ist es unvermeidlich, dass sie unterschiedliche Objektmodelle offen legen. Allerdings besteht auch anwendungsübergreifend ein gewisser Grad an Konsistenz. So ist das Objektmodell beispielsweise meist hierarchisch aufgebaut und hat allgemein ein Anwendungsobjekt als Basis. In Word können Sie mit dem Anwendungsobjekt beginnen, die Dokumentensammlung suchen, auf einzelne Dokumentobjekte und dann auf einzelne Bereichsobjekte zugreifen. Ebenso können Sie in Excel vom Anwendungsobjekt aus zur Arbeitsmappensammlung gehen, die Arbeitsmappenobjekte in der Sammlung suchen und dann individuelle Bereichsobjekte innerhalb einer Arbeitsmappe aufrufen.

Zudem sind die Visual Studio-Tools für Office schichtweise auf einem konsistenten, stark typisierten Objektmodell aufgebaut. Sie müssen sich nur zwei ganz verschiedene Visual Studio-Tools für Office-Lösungen, wie z. B. eine Excel-Lösung auf Dokumentbasis und eine Outlook-Lösung auf Anwendungsbasis, anschauen, um die Konsistenz zu erkennen. Beide Lösungen bieten einfache Methoden für den Start und das Beenden, und Sie können sich daher auf die Geschäftsanforderungen konzentrieren, ohne an die individuellen Merkmale der Hostanwendung denken zu müssen. Und obwohl Sie auch weiterhin vollen Zugriff auf die zugrunde liegenden Objektmodelle haben, können Sie wahlweise auch auf einer höheren Abstraktionsebene arbeiten.

Bei jeder neuen Programmversion hält Office einen sehr hohen Standard für die Abwärtskompatibilität aufrecht. Office-Anwendungen sind COM-Server, und COM erlegt einige Regeln auf, wie z. B. die Immutabilität von Schnittstellen, die vor Inkompatibilität zwischen verschiedenen Versionen schützt. Office hält sich meist an die Regeln. Alle Office-Schnittstellen sind entweder duale Schnittstellen oder reine Dispatch-Schnittstellen. Reine vtable-Schnittstellen (und daher auch duale Schnittstellen) sind unveränderlich, aber bei Dispatch-Schnittstellen ist dies nicht der Fall, weil der Satz der verfügbaren Funktionen und deren Signaturen bei Laufzeit erkennbar (und daher spät bindend) ist. Das Office-Team nutzt dies routinemäßig, indem es bei Veröffentlichung einer neuen Version weitere Methoden und Eigenschaften an das Ende einer Schnittstelle anhängt. Typischerweise fügt das Team vorhandenen Methoden auch neue optionale Parameter hinzu. Mit diesen Techniken kann Office die Abwärtskompatibilität aufrechterhalten.

Eine andere Technik für die Aufrechterhaltung von Versionsbeständigkeit ist die Verwendung einer losen Typbindung. Das klassische Beispiel hierfür ist die IDTExtensibility2-Schnittstelle, die von COM-Add-Ins implementiert werden muss. Wenn eine Office-Anwendung ein Add-In lädt, ruft die Anwendung IDTExtensibility2::OnConnection auf und reicht ein Objekt mit loser Typbindung ein, das die Hostanwendung darstellt. In .NET-Code wird dieser Parameter als ein System.Object typisiert, während er in C++ ein generischer IDispatch-Zeiger ist. Bei Laufzeit ist dies ein Zeiger zu dem von der Hostanwendung offen gelegten Anwendungsobjekt. Wenn Sie ein herkömmliches, gemeinsam genutztes Add-In entwickeln, ist der vom Assistenten generierte Code völlig hostneutral. Dies bietet zwei Vorteile: Das Add-In kann in allen Anwendungen ausgeführt werden, die COM-Add-Ins unterstützen, und das Add-In ist in jeder Version all dieser Anwendungen ausführbar.

Der Preis für ein solches hostneutrales Modell ist der Standardpreis für lose Typbindung und späte Bindung: Sie erhalten für die spezifischen beteiligten Typen keine Unterstützung zur Entwurfszeit oder Kompilierungszeit, da sie bis zur Laufzeit unbekannt sind. Das macht es erheblich einfacher, Code zu schreiben, der dann bei Laufzeit fehlschlägt. Zudem ist eine späte Bindung mit Leistungseinbußen verbunden, da jeder Methodenaufruf diesen Erkennungsprozess durchlaufen muss, um herauszufinden, ob zur Laufzeit wirklich eine passende Methode gefunden werden kann.

Wenn Sie Add-Ins mit .NET Framework entwickeln, können Sie diese lose Typbindung auch weiterhin verwenden, aber die Vorteile sind nur gering, es sei denn, das Add-In selbst bietet nur hostneutrale Funktionalität. Wenn das Add-In hostneutrale Funktionalität aufweisen muss, werden Sie wahrscheinlich die versionsspezifischen Primary Interop Assemblies (PIAs) des Hosts verwenden. Sie können auch Visual Studio-Tools für Office zum Entwickeln von Add-Ins mit .NET-Code verwenden. Visual Studio-Tools für Office schreibt eine starke Typisierung vor und bietet Ihnen so zusätzlich zur Typenüberprüfung zum Zeitpunkt der Kompilierung die Vorteile von IntelliSense® und automatische Vervollständigung zur Entwicklungszeit. Mit einer starken Typisierung vermeiden Sie auch den Leistungsaufwand einer späten Bindung.

Bedeutet eine starke Typisierung, dass Sie an Versionsbeständigkeit verlieren? Nicht unbedingt. Sie können ein Add-In mit loser Typbindung auf der Grundlage einer beliebigen Office-Version entwickeln, und es ist nahezu sicher, dass das Add-In vollständig in neueren Versionen von Office funktioniert. Mit .NET Framework können Sie dieselben Resultate erzielen, obwohl das Verhalten etwas komplizierter ist. Ein .NET-Add-In, das auf der Grundlage einer bestimmten Version der Office-PIAs entwickelt wurde, sollte auch in späteren Versionen funktionieren. Dies kann auf zwei verschiedene Arten stattfinden: Entweder verwendet das Add-In die Version der PIAs, auf deren Grundlage es entwickelt wurde, oder Sie stellen eine Bindungsumleitung für die PIAs bereit, damit das Add-In bei Laufzeit eine spätere Version der PIAs nutzt, die der installierten Version von Office entspricht.

Erweiterungspunkte

Seit den Anfangszeiten von Office war es aufgrund der Tatsache, dass Office-Clientanwendungen COM-Server sind und ihre Funktionalität daher für eine externe Automatisierung offen legen, möglich, die Funktionalität von Office zu erweitern. Diese Automatisierung kann sogar während des Prozesses in die Hostanwendung eingebettet werden. Gewöhnlich wird dazu VBA verwendet. Office bietet ein breites Spektrum von Erweiterungspunkten, und Sie können die Diagrammdarstellung so detailliert aufrufen, dass Sie die in Abbildung 4 aufgeführte Liste zu erhalten. Sie können diese Liste auf verschiedene Arten betrachten und analysieren. Abbildung 5 beschreibt die Techniken, die typischerweise eine Automatisierung der Office-Objektmodelle beinhalten, während Abbildung 6 Techniken aufzeigt, die andere Protokolle verwenden.

Abbildung 4: Office-Systemerweiterungspunkte
Abbildung 4: Office-Systemerweiterungspunkte

Dies ist eine große Bandbreite von Erweiterungspunkten. Wenn Sie eine Anwendungssuite über einen längeren Zeitraum hinweg entwickeln, erhalten Sie natürlich eine Reihe unterschiedlicher Verhaltensweisen, und dies gilt auch für Erweiterungspunkte. Beim Entwurf einer Entwicklungsplattform von Grund auf würden Sie selbstverständlich versuchen, die Erweiterungspunkte so konsistent wie möglich zu halten. Die Geschichte von Office ist weithin bekannt, aber sind die Erweiterungspunkte über die gesamte Breite der Anwendungssuite hin konsistent? Das heißt, können Sie in verschiedenen Anwendungen auf dieselbe Weise eine Verknüpfung mit demselben Funktionsbereich herstellen?

Auf einer Ebene sind die Techniken, die eine Art von Automatisierung der Office-Objektmodelle beinhalten, per definitionem konsistent. Das heißt, dass die Art, in der Sie die Objektmodelle verwenden, von standardmäßigen COM- und Automatisierungsregeln vorgegeben und begrenzt wird. Die einzelnen Office-Anwendungsobjektmodelle weisen einen gewissen Grad von Beständigkeit, aber letztlich unterschiedliche Funktionssätze auf. Wenn Sie eine Ebene tiefer gehen, unterscheidet sich so zum Beispiel die Art, in der Sie ein COM-Add-In kodieren, von der Art, in der Sie ein Smarttag kodieren. Dies liegt daran, dass ein Add-In IDTExtensibility2, ein Smarttag aber ISmartTagRecognizer oder ISmartTagAction implementieren muss. Offensichtlich wäre also der einzige Weg, auf dem diese beiden Funktionssätze konsistenter gemacht werden könnten, eine Kombination der Schnittstellen. Die Idee einer einzelnen Erweiterungsschnittstelle für alle Typen erweiterbarer Funktionen mag wohl attraktiv erscheinen, aber eine solche Schnittstelle wäre entweder stark eingeschränkt oder hätte einen sehr unbestimmten Anwendungsbereich.

Anstatt also Schnittstellen zu kombinieren, werden mit Office 2007 fünf neue Erweiterungsschnittstellen eingeführt, die vier Funktionsbereiche abdecken (siehe Abbildung 7). Das Interessante an diesen neuen Schnittstellen ist, dass sie zwar in ihrer Funktionalität ganz unterschiedlich sind, aber alle über ein COM-Standard-Add-In implementiert werden können. Dies war eine bewusste Entwicklungsentscheidung und ist auch ein Indikator für die Roadmap für die künftige Office-Erweiterbarkeit. Die COM-Add-In-Technologie ist bewährt, wird gut verstanden und von Entwickler-Tools gut unterstützt. Die Prozesse für die Bereitstellung und Verwaltung von Add-Ins sind ebenfalls wohl definiert und Administratoren vertraut. Es ergibt ganz klar einen Sinn, auf diese Weise einen konsistenten Erweiterungspunkt zu bieten: nicht mit der Entwicklung einer einzelnen Erweiterungsschnittstelle, sondern indem zugelassen wird, dass eine einzelne Implementierung eine oder mehrere der wachsenden Anzahl von Erweiterungsschnittstellen verwendet. Bei dieser Vorgehensweise hätten Entwickler und Administratoren nur ein Modell, um das sie sich Gedanken machen müssen.

Diese Konvergenz von Erweiterungstechniken mit dem Add-In-Modell scheint der Entwurf für alle künftigen Erweiterungsschnittstellen zu sein. Wäre diese Vorgehensweise auch auf vorhandene Schnittstellen anwendbar? Könnten Sie zum Beispiel ein Smarttag über ein Add-In implementieren? Könnten Sie eine Excel-Funktion über ein Add-In implementieren? Technisch gesehen könnte dies sogar möglich sein, ist aber wahrscheinlich nicht der beste Weg. Für neue Schnittstellen ist es sinnvoll, aber der Nachteil des Versuchs, diese Methode auf alte Schnittstellen anzuwenden, besteht darin, dass es bereits viele Lösungen gibt, die die alte Vorgehensweise verwenden. Wenn Sie Excel-Funktionen sowohl über herkömmliche Add-Ins als auch über Automatisierungs-Add-Ins implementieren könnten, könnten Sie dieselben Ergebnisse auf zwei verschiedene Arten erhalten. Daher bringt das Ideal des Zusammenführungs- oder Konvergenzentwurfs eine divergierende Bereitstellung mit sich. Dies kann für eine Übergangsphase annehmbar sein, während Entwickler ihre Lösungen vom alten Modell zum neuen migrieren. Zurzeit unterstützen Add-Ins die anderen alten Erweiterungsschnittstellen nicht, aber dies kann eine Richtung für die Zukunft sein, die vielleicht von einer Nachfrage seitens der Kunden abhängt.

Bei einer Betrachtung von Erweiterungspunkten sollten auch die Formate von Dokumentdateien einbezogen werden. Eine Art, in der sich Office erweiterbar macht, ist die Bereitstellung von programmtechnischem Zugriff auf seine Dokumente. In den jüngsten Versionen von Office wurde ein gewisser Grad von Unterstützung für XML eingeführt. So bot Excel früher zum Beispiel nur minimale Unterstützung für das Lesen und Schreiben von XML. Diese Unterstützung wurde schrittweise erhöht und hat auch in anderen Anwendungen Verbreitung gefunden, speziell in Access, InfoPath, PowerPoint® und Word. Office 2007 unterstützt nun vollständig Open XML-Dateiformate für Excel, PowerPoint und Word.

Die Open XML-Formate schaffen neue Möglichkeiten für Entwickler, da Lösungen nun mittels tiefer Integrierung mit dem Dokumentinhalt erweitert werden können. Das folgt der Einreichung bei ECMA International von Open XML-Formaten als ein vorgeschlagener offener Standard. Microsoft arbeitet daran, die Möglichkeiten für eine unabhängige Entwicklung in einigen viel versprechenden Bereichen zu unterstützen. Es gibt sogar eine neue, offene technische Community von Entwicklern mit dem Namen „Open XML Formats Developer Group“, in der auch vierzig Branchenführer wie Intel, Apple, BP und Toshiba Mitglied sind.

Die Verwendung von XML bietet die Vorteile höherer Transparenz und Offenheit, als dies mit den vorherigen binären Dateiformaten möglich war. Die neuen Formate ermöglichen eine einfache Integrierung von Office-Dokumenten mit vorhandenen und künftigen Geschäftssystemen, da die Inhalte jetzt offen und zugänglich sind. Dabei werden ganz klar Server- und Skalierbarkeitsprobleme berücksichtigt: Für viele Lösungen ist es nicht notwendig, Office auf dem Server zu automatisieren, da Sie die Dateien direkt bearbeiten können. Die neuen Formate wurden auch unter Berücksichtigung langfristiger Robustheit und problemlosen Zugriffs entworfen, damit eine beschädigte Datei einfach repariert werden kann und der Zugriff auf den Dokumentinhalt keinen Verlass auf eine bestimmte Softwareanwendung erfordert. Die Dateien der Version 2007 sind zudem sehr viel effizienter, nehmen weitaus weniger Platz als die früheren Formate ein und ermöglichen so kürzere Übertragungszeiten und eine geringere Speicherbelastung.

Die neue Dateiformate sind ein wichtiger Schritt nach vorn und werden nicht nur für solche Kunden bereitgestellt, die die Version 2007 anwenden, sondern auch für Kunden, die mit früheren Versionen von Office arbeiten. Mit kostenlosen Konvertierungstools können Benutzer von Office 2000, Office XP und Office 2003 die neuen Formate öffnen und in diesen speichern, und so kann jeder von dieser Innovation profitieren.

Das Entwicklungs-Toolset von Office

Eine Sichtweise lautet, dass eine Entwicklungsplattform nur ihre Erweiterungspunkte offen legen und nicht zudem ein Toolset bereitstellen muss. Diese Alternative ist bis zu einem gewissen Punkt reine Theorie, da Microsoft in der Tat Tools für die Entwicklung mit Office bereitstellt. Daher ist die wirklich relevante Frage, ob das dargebotene Toolset die Plattform ausreichend unterstützt.

Mit Blick auf die Tools können Sie Office-Lösungen mit einer Vielzahl von Frameworks und Sprachen entwickeln. Für die externe Automatisierung von Office können Sie jede beliebige COM-kompatible Sprache verwenden. Für die interne (dokumentbasierte) Automatisierung von Office können Sie VBA einsetzen. Bei der Arbeit mit .NET Framework können Entwickler Visual Studio-Tools für Office verwenden, wenn sie ein strukturiertes, konsistentes Toolset und eine ebensolche Laufzeit haben möchten. In Abbildung 8 sehen Sie eine Zuordnung der Erweiterungspunkte zu den verfügbaren Tools.

VBA deckt nur eine kleine Auswahl der zur Verfügung stehenden Erweiterungspunkte ab. Das liegt hauptsächlich daran, dass VBA auf dokumentbasierte Lösungen begrenzt ist. Mit einer Kombination aus herkömmlichen gemeinsam genutzten Add-In- und Visual Studio-Tools für Office-Lösungen können Sie die meisten Erweiterungspunkte nutzen. Die Visual Studio-Tools für Office decken zahlenmäßig etwas mehr ab, weil sie auch einige der Einmal-Erweiterungstypen umfassen. So können Sie zum Beispiel ein Smarttag nicht als ein herkömmliches Add-In entwickeln, aber Sie können es als eine Einmal-DLL oder ein Visual Studio-Tools für Office-Add-In erstellen.

Die Laufzeit von Visual Studio-Tools für Office bietet wesentliche Dienste, die für eine große Bandbreite von Funktionen optimiert ist. Sie haben wahlweise auch die Flexibilität, Lösungen ohne Visual Studio-Tools für Office zu erstellen, wenn Sie eine benutzerdefinierte Laufzeitinfrastruktur entwickeln müssen. Betrachten Sie zum Beispiel COM-Add-Ins. Gegenwärtig stehen Ihnen zwei Toolset-Hauptwahlmöglichkeiten für die Entwicklung von Add-Ins zur Verfügung: die herkömmlichen, gemeinsam genutzten Add-In-Projekttypen und Visual Studio-Tools für Office-Add-Ins.

Diese Situation ist allerdings nicht gerade ideal. Eine bessere Lösung wäre ein einziger Projekttyp mit allen Fähigkeiten sowohl gemeinsam genutzter als auch Visual Studio-Tools für Office-Add-Ins. Das ist natürlich schwer zu erreichen, weil gemeinsam genutzte Add-Ins grundsätzlich eine lose, während Visual Studio-Tools für Office-Add-Ins grundsätzlich eine starke Typbindung aufweisen. Dieser Unterschied verleiht den gemeinsam genutzten Add-Ins die Fähigkeit, in mehreren Versionen von Office zu funktionieren, während im Gegensatz dazu die Visual Studio-Tools für Office-Add-Ins eine bessere Handhabung zur Entwurfszeit und eine erheblich verbesserte Robustheit zur Laufzeit aufweisen.

Mangels des Ideals würde das optimale Toolset diese beiden Projekttypen rationalisieren, sie so konsistent wie möglich machen und die Wahl der Entwickler vereinfachen. Ein Beispiel: Die Organisation der Visual Studio-Tools für Office-Add-Ins ist anders als die aller anderen Projekttypen in Visual Studio, da sie Stammknoten aufweisen, die der Programmiersprache entsprechen. Im Gegensatz dazu bieten die gemeinsam genutzten Add-Ins dem Entwickler als ein Schritt im Projektassistenten die Möglichkeit, die Sprache zu wählen. Ein weiteres Beispiel ist, dass Visual Studio-Tools für Office-Add-Ins dem Entwickler bezüglich der für den Registrierungswert „Description“ zu verwendenden Zeichenfolge keine Wahl lassen, da die Zeichenfolge jederzeit geändert werden kann, nachdem der Assistent das Projekt erstellt hat. Dieser Wert wird aber von Office niemals verwendet. Andererseits fordern die gemeinsam genutzten Add-Ins Sie auf, diese Zeichenfolge bereitzustellen, die in den meisten Fällen redundant ist.

Wie passt VBA in das Entwicklungs-Toolset von Office? VBA wurde ursprünglich eingeführt, um die Entwicklung seitens Nicht-Profis, das heißt von Hauptbenutzern bzw. „Power Usern“ (Profis in ihren eigenen Fachgebieten, aber nicht unbedingt Profis in der Softwareentwicklung) zu unterstützen, die den Basisfunktionssatz von Office erweitern müssen, um domänenspezifischere Lösungen bereitzustellen. Eine Verwendung von VBA für hoch komplexe, professionelle Lösungen war niemals beabsichtigt, aber mangels einer guten Alternative wurde VBA in dieser Rolle benutzt. Visual Studio-Tools für Office befinden sich am anderen Ende des Spektrums. Sie sind ein professionelles Entwicklungs-Tool, das die volle Leistungsfähigkeit von Visual Studio und eine verwaltete Entwicklung in Office einbringt.

Natürlich können VBA und Visual Studio-Tools für Office nebeneinander existieren, und die mit diesen Technologien entwickelten Lösungstypen überschneiden sich in erheblichem Maße. Für viele Lösungen könnten Sie die eine oder die andere oder sogar beide Technologien verwenden (obwohl diese Vorgehensweise wahrscheinlich auf Übergangsobjekte beschränkt ist, die im Lauf der Zeit von VBA migriert werden).

Visual Studio-Tools für Office decken mit Sicherheit das obere Ende der Skala ab und reichen bis an das untere Ende heran, bieten aber keine Makroaufzeichnung. Dies ist ein Bereich, in dem VBA immer noch das einzige Tool für nicht-professionelle, auf Benutzerinteraktion basierte Lösungen ist. Nochmals: Ideal wäre, wenn ein Toolset das gesamte Spektrum abdecken würde. Vor diesem Hintergrund untersucht Microsoft das Problem intensiv und erwägt Möglichkeiten, wie mit Visual Studio-Tools für Office die Low-End-Makroaufzeichnungsfähigkeiten von VBA abgedeckt werden könnten.

Weitere Vorteile von Office

Bisher haben Sie starke Argumente für Office als eine Entwicklungsplattform gelesen, aber Office bietet noch viel mehr. Beachten Sie, dass Office die Hauptbenutzeroberfläche für Information Worker ist. Dies ist keine Voraussetzung für eine Entwicklungsplattform, ist aber natürlich ein riesiger Bonus. Information Worker fordern Anwendungen, die mit Hinblick auf Office entwickelt sind. Die Office-Benutzeroberfläche ist vertraut, der Office-Anwendungsworkflow ist vertraut, und viele Aufgaben erfordern spezifische Office-Funktionen. Darüber hinaus benötigen diese Information Worker Anwendungen, die ihnen eine nahtlose Interaktion zwischen dem Office-Host und der benutzerdefinierten Lösungsfunktionalität ermöglichen.

Können Sie mit Office Lösungen entwickeln, bei denen Ihre benutzerdefinierte Funktionalität nahtlos mit der Funktionalität der nativen Anwendung interagiert? Sehen die benutzerdefinierten Lösungen aus, als ob sie Teil des Hosts sind? Betrachten Sie einmal die Befehlsbenutzeroberfläche, d. h. die Multifunktionsleiste in Office 2007, und die äquivalenten Befehlsleisten früherer Versionen. Wenn Sie eine benutzerspezifische Anpassung der Multifunktionsleiste oder der Befehlsleisten bereitstellen, verhalten sich diese benutzerdefinierten Steuerungen und Menüelemente genau so wie die integrierten Steuerelemente. Wenn Sie eine benutzerdefinierte Excel-Funktion entwickeln, kann diese auf genau dieselbe Weise wie eine integrierte Funktion verwendet werden, obwohl eingeschränkt ist, auf welcher Ebene Sie kontextbezogene Hilfeunterstützung bereitstellen können. Benutzerdefinierte Formularregionen in Outlook sind entwicklungstechnisch für eine nahtlose Integration mit den internen Formularen ausgelegt, und Sie haben sogar mehrere Wahlmöglichkeiten, wie diese Integration dargestellt wird.

Das Office-Programmierbarkeitsteam hat sich größte Mühe gegeben sicherzustellen, dass Erweiterungsfunktionen, die von benutzerdefinierten Lösungen implementiert werden, so nahtlos wie möglich in die Hostanwendung integriert werden. Das Ergebnis ist, dass der Endbenutzer die angepasste Lösung als eine natürlich Erweiterung von Office sieht.

Ein Punkt, der hier erwähnt werden sollte, ist, dass Office bestimmte Erweiterungspunkte auf eine uneingeschränkte Weise offen legt, was potenziell zu Missbrauch führen kann. So können Sie in der Outlook-Ansicht „Ordnerliste“ HTML in das Outlook-Fenster einfügen, und der HTML-Code könnte ActiveX®-Steuerelemente enthalten. Dies kann ins Extreme weitergeführt werden, weil Outlook keine Kenntnis von den Steuerelementen hat, die Sie hier platzieren können, und keine Beschränkungen auf deren Verhalten auferlegen kann. Insgesamt bieten Ihnen die Erweiterungs-Features von Office all die Flexibilität, die Sie brauchen, aber Sie sollten die Plattform mit Vernunft nutzen.

Eine ernsthafte Entwicklungsplattform

Sie haben gesehen, dass Office alle Attribute einer ernsthaften Unternehmensentwicklungsplattform aufweist. Office bietet einen umfassenden Basisfunktionssatz, eine Palette von Erweiterungspunkten und eine Auswahl von Entwicklungs-Toolsets. Office ist nicht perfekt und hat einige kuriose Anomalien und Inkonsistenzen, aber wenn man seine Geschichte bedenkt, ist es wirklich bemerkenswert, wie weit diese Anwendungssuite einer kohäsiven Plattform angenähert hat. Die Grundfunktionen sind äußerst umfassend. Die Erweiterungspunkte sind noch etwas holprig, und es könnte mehr von ihnen geben. Die Entwicklungs-Toolsets befinden sich noch in der Weiterentwicklung und könnten etwas rationalisiert werden. Es bleibt also noch Einiges zu tun, und das unterstützende Toolset muss im Gleichschritt mit der Plattform selbst weiterentwickelt werden, aber es gibt Anzeichen dafür, dass die strategische Richtung für die Zukunft von Office die Entfaltung in eine Entwicklungsplattform der Weltklasse ist.

Die Autoren

Andrew Whitechapel hat viele Jahre als Berater für Architekten verbracht und Unternehmenslösungen für eine große Bandbreite von Kunden entwickelt; er ist heute Program Manager Technical Lead für das VSTO-Team bei Microsoft.

John Peltonen und seine Firma, 3Sharp, sind passionierte Architekten und Entwickler von Office-Systemlösungen. Weitere Informationen über John und seine Mitarbeiter finden Sie unter blogs.3sharp.com

Ausgabe von August 2006 des MSDN-Magazins.