bitwork GmbH

Vogelsanger Str. 42-48

58300 Wetter

Telefon:

0 23 35 / 84 75 - 0

Telefax:

0 23 35 / 84 75 - 111

E-Mail:

info@bitwork.net

Smart Client-Entwicklung für Office 2007

.NET-basierte SmartClient-Entwicklung für Microsoft Office 2007

Microsoft Office in der Version 2007 bringt einige revolutionäre Neuerungen, z.B. in der Benutzeroberfläche - aber auch in der Art und Weise, wie Entwickler eigene Anwendungen unter dem Dach des weit verbreiteten Office Systems spielen lassen und dabei auf eine reichhaltige Fülle von Funktionen und Funktionalität zurückgreifen können. Das ist kompliziert und unsicher? Mitnichten! Hinter vielem steckt XML und Visual Studio Tools für Office (VSTO) reduziert die Barriere für Entwickler auf ein Minimum. Dieses Feature vermittelt auf Basis der Beta 1 (Technical Refresh)-Version erste Eindrücke und technische Grundlagen für Office Developer mit .NET-Neigung.

Ribbons - die neue Benutzeroberfläche

Office 2007 besitzt keine Menüs mehr!
Uups - was gibt es denn jetzt? Ribbons.

Doch erst mal langsam und ein wenig in der Vergangenheit geforscht: wenn man sich die einzelnen Versionen von Microsoft Office im Zeitraffer anschaut, so erkennt man schnell, was die Ursache für diese radikale Oberflächenänderung war. Übersichtlichkeit. Es sind mit der Zeit immer neue Befehle hinzugekommen und die mussten irgendwo hin. Irgendwann gab es Menüs (wir wollen hier nicht über die Zeiten sprechen, wo die Befehle noch "schön" nebeneinander standen und über einen Buchstaben abgewählt wurden, sondern von grafischen Benutzeroberflächen). Als das nicht mehr ausreichte, wurden Toolbars und geschachtelte Menüs eingeführt. Danach kam die Aufgabenleiste, auch Taskpane genannt. Und von all dem gibt es sehr viele unterschiedliche Ausprägungen.

Manch einer wird behaupten, sich ganz gut in Office zurechtzufinden. Aber dennoch sucht man manchmal nach einer Funktion, von der man weiß, dass sie da ist. Nur wo? Und wo soll man anfangen zu suchen? Geht es Ihnen auch so? Dann sind Sie reif für Ribbons. Ribbons sind auf den ersten Blick Tabbed Dialog Controls. Kombiniert mit Toolbars bieten sie auf den zweiten Blick aber noch viel mehr. Die Befehle werden entsprechend des aktuellen Kontexts bereitgestellt, also alles Einfügbare wird unter "Insert" zu finden sein, datenbezogen Befehle im Reiter "Data". Somit verspricht die neue Oberfläche, das Gesuchte schneller und mit weniger Klicks zu finden.

Jeder Ribbon Tab besteht aus Gruppen, in denen wiederum die Controls liegen. Das können neben den bekannten Steuerelementen (Button, EditBox, ComboBox, DropDown, Menu) auch Split- bzw. ToggleButton, Label, CheckBox oder Gallery sein. Letztere ist besonders interessant, gibt sie doch dem Anwender eine visuelle Repräsentation des zu erwartenden Ergebnisses. In Verbindung damit kommt eine weitere Neuerung zum Einsatz: der Live Preview. Denn je nach ausgewähltem Gallery-Eintrag wird das im Dokument befindliche Objekt sofort die gewählte Formatierung annehmen. Temporär, versteht sich. Bis ein Eintrag endgültig ausgewählt wurde.

Auch hier hat der Entwickler gute Karten. Ribbons werden mittels XML-Formaten beschrieben und entweder direkt in die Datei gepackt oder per Add-In zur Laufzeit integriert. Solch eine Ribbon-Erweiterung in XML könnte dann folgendermaßen aussehen:

<tabs>
  <tab id="TabMicrosoft" label="Microsoft" visible="1">
    <group id="grpAction" label="Action Group" visible="1">
      <button id="btnShowEmployees" label="Show Employees" 
              onAction="ShowEmplHandler"/>
      <button id="btnGetCustomers" label="Get Customers" 
              onAction="GetCustHandler"/>
    </group>
  </tab>
</tabs>

Wir müssen uns auch nicht mit dem COM Interface IRibbonExtensibility auseinandersetzen, wir bekommen nämlich Visual Studio Tools für Office (VSTO) für diese Zwecke. Wieso eigentlich COM? Programmieren wir nicht mit .NET? Stimmt, aber Office setzt immer noch auf der COM-Technologie auf und wir müssen einen Weg finden, die Interoperabilität herzustellen. Diese Schicht stellen die Primary Interop Assemblies dar, quasi ein Interop Wrapper für das Objektmodell von Office. Visual Studio Tools für Office setzt genau hier auf.

Das neue Dateiformat von Office 2007

Office 2007 goes XML.
Proprietäre Formate mögen zwar performanter sein, lassen aber wenig Raum für Kreativität und schränken die Möglichkeiten von Entwicklern ein.
WordProcessingML bzw. SpreadsheetML (Office2003 XML Reference Schemas (http://www.microsoft.com/office/xml/default.mspx), ein-geführt mit Office 2003, bot zwar schon die Möglichkeit, vollständig formatierte Dokumente im XML-Format abzuspeichern, erwies sich aber als unstrukturiert und zu komplex.

Die neue Version hingegen bringt das Open XML Format (http://www.microsoft.com/office/preview/itpro/fileoverview.mspx) und verbindet damit das XML-Format mit der ZIP-Technologie, um zum einen die Übersichtlichkeit zu wahren und zum anderen die Größe der Dateien zu reduzieren. Und das gelingt eindrucksvoll. Das neue Dateiformat verspricht Einsparungen von 50-75% sowie eine nie da gewesene Robustheit. Die einzelnen Bestandteile der Datei – sog. Parts – sind wiederum XML-Dateien. Sie sind atomar, also in sich abgeschlossen. Das führt dazu, dass die Office-Programme fehlerhafte Parts einfach ignorieren und die gesamte Datei trotzdem öffnen können. Zwar fehlt dann dieser Part, vielleicht die Schriftartentabelle oder Formatierung, aber der Zugriff auf den Inhalt wird nicht verwehrt.

.NET-Entwickler können neue APIs im Namespace System.IO.Packaging bzw. vorhandene aus System.XML verwenden, um die neuen Office-Formate zu öffnen bzw. zu speichern oder die einzelnen Bestandteile herauszuziehen bzw. wieder hineinzubringen. Die o.g. Packaging APIs werden Bestandteil von WinFx, dem zukünfigen Programmier-Framework sein. Keine Sorge, WinFx wird auch für gerade aktuelle Systeme wie Windows XP SP2 oder Windows Server 2003 zur Verfügung gestellt werden.

Somit können Entwickler ohne eine Instanz eines Office-Programms verwenden zu müssen (Office muss hier nicht einmal installiert sein), Dateien erzeugen oder Daten in bestehende Dateien ablegen und damit bspw. Dokumente personalisieren. Abenteuerliche Szenarien, wo auf dem Server Instanzen von Word oder Excel erzeugt werden müssen und ein Windows Service die Prozesse überwacht und ggf. diese Instanzen aus dem Speicher entfernt, gehören damit der Vergangenheit an.

Document ActionsPane und Custom TaskPane

Der eine oder andere wird es schon in Office 2003 entdeckt haben - die Document ActionsPane. Ein Fenster auf der rechten (oder linken) Seite des Dokuments, in dem eigene Funktionalität implementiert werden kann. Diese kommt zum Einsatz, wenn sog. Smart Documents gebaut werden. Die Idee von Smart Documents ist nicht wirklich neu. Schon im Jahre 2003 konnte man unter Zuhilfenahme von ISmartDocument, einer COM-Schnittstelle, oft benötigte Funktionalität aus eigenen Anwendungen direkt in Office bringen. Die Erfahrung des Programmierens war allerdings eine mühsame. Auch hier hilft uns wieder VSTO mit einem .NET-Programmiermodell für die ActionsPane. Während früher mehrere Seiten Quellcode nötig waren, um ActiveX (bzw. COM) Controls in die ActionsPane zu bringen, können wir heute .NET (User) Controls mit nur einer Zeile Code hinzufügen:

Erlaubt ist, was gefällt. Nur wenige der vielen managed Controls aus Visual Studio 2005 lassen sich nicht integrieren. Die Idee bei einer ActionsPane ist, oft verwendete Daten aus LOB-Anwendungen (Line-of-Business-Anwendungen: z.B. ERP- oder CRM-Systeme) direkt in Office verfügbar zu machen.

Denn sind wir mal ehrlich: Die Clients von Anwendungen wie Siebel oder SAP sind zwar sehr mächtig in ihren Möglichkeiten, aber für Gelegenheitsbenutzer doch ziemlich erschlagend.

Eine Integration spart eine Menge Einarbeitungszeit für die Mitarbeiter, denn Microsoft Office ist weit verbreitet, bekannt und akzeptiert. Außerdem ersparen wir uns das Hin-und-Herspringen bzw. –kopieren zwischen Anwendungen.

Was ist jetzt der Unterschied zwischen Document ActionsPane und Custom TaskPane? Ganz einfach: die Document ActionsPane ist an ein Dokument oder eine Vorlage gebunden und die Custom TaskPane existiert anwendungsweit. Haben Sie also Funktionalität, die auf die Struktur eines Dokuments aufbaut (Smart Document), so arbeiten Sie mit der Document ActionsPane. Ihre Lösung wird vom VSTO Loader automatisch beim Öffnen des Dokuments geladen. Wollen Sie im Gegensatz dazu allgemeine Daten zur Verfügung stellen, egal welches Dokument gerade aktiv ist, dann verwenden Sie eine Custom TaskPane.

Managed Add-Ins für alle

Microsoft Office kennt COM Add-Ins schon seit Urzeiten. Nur was machen wir in Zeiten von .NET? Ja, es gibt die Möglichkeit, sog. Shared Add-Ins zu schreiben. Doch wenn wir ein wenig hinter die Kulissen schauen, wird schnell klar, warum das nicht so gut ist. Mal abgesehen davon, dass wir von den fünf Events, die uns IDTExtensibility2 anbietet, sowieso nur zwei brauchen, werden Shared Add-Ins in die gleiche Application Domain (AppDomain) geladen. Wenn alle geladenen Add-Ins korrekt programmiert sind und sich an die Regeln halten, ist das auch kein Problem. Aber wehe, wenn auch nur eines Probleme bereitet und sich verabschiedet. Es nimmt beim Sterben die AppDomain mit und damit alle anderen Add-Ins.

Mit der Sicherheit sieht es ähnlich aus. Die ins .NET Framework eingebaute Code Access Security, welche uns erlaubt, Rechte für Anwendungen festzulegen, greift hier nicht. Wir haben keine Shim (eine unmanaged Proxy-Komponente) gegen die wir die Sicherheit festlegen könnten und müssten das gegen die mscoree.dll – der Mutter von .NET (Haupteinsprungspunkt der Common Language Runtime) – tun. Das macht aber wiederum keinen Sinn, da das dann auf alle .NET Programme angewendet werden würde und somit die Security ausgehebelt wäre.

Die Lösung heißt wieder einmal VSTO. Es wird eine entsprechende Shim zur Verfügung gestellt und die Add-Ins werden in jeweils eigene AppDomains geladen, so dass sie sich nicht mehr gegenseitig beeinflussen können. VSTO stellt isolierte managed Add-Ins für alle Office-Programme zur Verfügung, von Access bis Visio. Dabei wird ebenfalls Schluss gemacht mit den fünf teils verwirrenden Events (OnConnection, OnAddInsUpdate, OnStartupComplete, OnBeginShutdown und OnDisconnection). Dafür gibt es nun Startup und Shutdown.

Server-Seitige Szenarien

Durch die Unterstützung des Open XML Formats bieten sich wie o.g. einige interessante Integrationsszenarien auf dem Server oder überall dort, wo keine Instanzen von Office verwendet werden können. Des Weiteren bietet VSTO eine direkte Unterstützung dafür, Daten in sog. Data Islands abzulegen. Jede serialisierbare Datenstruktur bzw. deren Inhalt kann hierbei automatisch beim Speichern des Dokuments abgelegt werden. Der Entwickler muss dafür lediglich das Cached-Attribut in seinem Code setzen und die Datenstruktur als öffentlich deklarieren.

[Microsoft.VisualStudio.Tools.Applications.Runtime.Cached()]
public SurveysDataSet surveysDataSetCached;

Zusammen mit dem SharePoint Server ist dies eine unschlagbare Kombination. Stellen Sie sich bitte folgendes Szenario vor:

Ein Formular (Word-Dokument) wird von einem Anwender via Browser aus einer SharePoint Document Library geöffnet. SharePoint feuert einen Event und Server-seitiger Code ermittelt die Identität des Anwenders. Nun werden personalisierte Daten aus angeschlossenen Systemen geholt und im DataIsland des Dokuments abgelegt. Der Anwender bemerkt von dem ganzen Vorgang nur insofern etwas, als dass er die personalisierten Daten an der korrekten Stelle im Dokument sieht (Grund: Datenbindung mit ViewControls). Nun füllt er das Formular weiter aus und speichert es. Da Office von Haus aus Shared Workspaces unterstützt, wird das Dokument automatisch am richtigen Platz, nämlich der Document Library gespeichert, wobei man hier als Entwickler natürlich auch eingreifen kann. Die Document Library feuert nun wieder einen Event, was dazu führt, dass ein anderes Stück server-seitigen Codes die Änderungen aus dem Dokument holt und in der richtigen Datenbank ablegt.

Deployment

Bei Administratoren zählt der Ausspruch von Entwicklern "… aber bei mir funktioniert es ..." wohl zu den meistgehörten Kommentaren. Und spätestens wenn die eigene Lösung fertig gestellt ist, wird irgendjemand sie irgendwo einsetzen wollen. Dafür muss sie vorbereitet sein.

Microsoft hat mit .NET für Office ein neues Kapitel für Office-Lösungen aufgeschlagen. Waren VBA-Erweiterungen dezentral auf der Anwendermaschine abgelegt, so befinden sich VSTO-Lösungen i.d.R. zentral auf einem Server und können somit sehr gut gewartet und Updates eingespielt werden. Lösungen für Office 2007 verwenden ClickOnce Deployment – eine Technologie, die es jetzt schon für Desktop-Anwendungen auf Basis des .NET Framework 2.0 gibt. Sie werden digital signiert und auf Basis dieser Signatur werden die Rechte festgelegt. Per Solution wohlgemerkt, nicht per User! Kennt der Client die Signatur und wird dieser vertraut, werden die erforderlichen Rechte zugewiesen. Der Mechanismus, der dies erlaubt, ist tief ins .NET Framework integriert und nennt sich Code Access Security. Somit können auch Office-Lösungen auf ein ganz neues Sicherheitsniveau gehoben werden und Makroviren haben wohl keine Chance mehr.

Microsoft Office System bietet weit mehr Anwendungen und Technologien als hier dargestellt werden können. Mit Excel Server können Excel-Tabellen im Intranet auf einer Web-Oberfläche bereitgestellt werden – mit Eingabemöglichkeiten, um bspw. Berechnungen durchzuführen. SharePoint wurde um viele Funktionen erweitert, von Versionskontrollmechanismen bis zum Content Management. InfoPath Formulare können nun direkt im Browser dargestellt werden u.v.w.m.

Quelle

Blog Jens Häupel
MSDN Deutschland