Verteilung von VSTO 2005 SE – Lösungen [Teil 1]


Da immer noch (;-) viele mit Visual Studio 2005 und VSTO 2005 SE arbeiten, will ich hier einen vor etwa 6 Monaten veröffentlichten Artikel zum Thema Packetierung und Deployment aufarbeiten und zur Verfügung stellen.

 

Lösungen für Microsoft Office zu schreiben war noch nie so einfach wie mit Visual Studio 2005 Tools for the Microsoft Office System Second Edition (kurz VSTO 2005 SE). Nur leider steht zwischen Entwicklung und Einsatz noch die Verteilung und Installation der Pakete. Dass das leicht zum Albtraum werden kann, weiß sicher der eine oder andere zu berichten. Hier soll vorgestellt werden, welche Schritte gegangen werden müssen, um eine erfolgreiche Installation zu erreichen.

 

Vorüberlegungen

Jeder Installation sollte sorgfältige Planung vorausgehen. So auch bei der Verteilung von Office-Lösungen. Je komplexer die Zusammenhänge sind, um so mehr Zeit sollte für die Erstellung funktionierender Setups und deren Testing eingeplant werden. Paketierung von Software ist ebenso ein Prozess des Software Life Cycle wie jeder andere auch. Speziell für Office-Lösungen auf Basis von VSTO gibt es folgendes zu bedenken bzw. planen:

· Deployment Modell wählen [4]

· Prerequisites auf dem Zielsystem installieren

· Eigene Lösung für das Deployment vorbereiten

· Dateien auf den Deployment Server kopieren

· Erforderliche Registry Einträge erzeugen (Add-In Lösungen)

· Code Access Security für die Assemblies setzen

Aufgaben können zusammengezogen oder getrennt voneinander abgearbeitet werden. Es kommt sehr stark auf die Umgebung an. Zum Beispiel wird man in Unternehmensumgebungen mit Administratoren für die Netzwerkumgebung wohl kaum die Security-Einstellungen mit der eigentlichen Installation verbinden. Auch die Prerequisites werden dort i.d.R. und bedingt durch andere Anforderungen getrennt von den Anwendungen installiert. Sie Lösung selbst kann ebenfalls Auslöser für derartige Überlegungen sein. Bei dokumentzentrischen Lösungen könnte man das Dokument per email schicken oder auf einen File Share bzw. eine SharePoint Dokumentbibliothek legen und die dazugehörige Lösung zentral auf einem Server verwalten. Bei Programm-Updates muss dann nur eine einzige Stelle berührt werden, die Clients werden automatisch das Update bekommen.

 

Software Publishing

Diese eben beschriebene Art und Weise der Verteilung nennt man Software Publishing. Die in das .NET Framework eingebaute Technologie ClickOnce hat es vorgemacht. Per HTTP, FTP oder UNC wird ein Link auf ein sog. Deployment Manifest zur Verfügung gestellt, welches wiederum auf die gerade aktuelle Version der Lösung zeigt. Wird der Link aktiviert, so installiert sich (Berechtigungen einmal vorausgesetzt) die Lösung in das User Profile des angemeldeten Benutzers. Es werden keine erweiterten Rechte dazu benötigt. Bei jedem Start schaut dann der Client, ob eine neuere Version zur Verfügung steht und wird diese bei Bedarf installieren.

So ähnlich funktioniert das auch mit VSTO-Lösungen („echtes“ ClickOnce für VSTO wird es erst mit Visual Studio 2008 geben, da dort der ClickOnce-Mechanismus in Bezug auf die Unterstützung von DLL-Assemblies erweitert wurde). Derzeit ist es noch mit etwas mehr Aufwand verbunden, muss doch z.B. das Manifest bei dokumentzentrischen Lösungen in einem separaten Arbeitsschritt angepasst werden, so dass es auf die neue (Server-) Lokation der Assembly zeigt. Dieses Manifest ist ins Dokument eingebettet. Somit benötigt man einen Manifest Editor [5] oder bedient sich der ServerDocument Klasse aus dem VSTO-Namespace, welche Methoden besitzt, die auf das Manifest zugreifen zu können.

Bei Add-Ins muss dafür ebenfalls der Pfad angepasst werden, über den der Office Toolkit Loader die Customization Assembly auf dem Server findet. Diese Art der zentralen Ablage von Add-Ins ist allerdings eher selten anzutreffen.

Da bei dokumentzentrischen Lösungen die Assembly lokal kopiert wird, ist die Lösung auch Offline-fähig, sofern die selbst geschriebene Logik nicht eine Verbindung zu Servern benötigt. Hilfreich könnte hier der Smart Client Offline Application Block aus Patterns & Practices [6] sein.

 

Die Hilfe der Zauberer

Projektvorlagen und Assistenten erleichtern die Erstellung einer VSTO-Lösung erheblich. So werden beispielsweise Proxy-Klassen angelegt, die .NET managed Code erlaubt, mit der Office zugrunde liegenden COM-Technologie zusammen zu arbeiten. Desweiteren wird ein Setup-Projekt generiert, dass den primären Projekt-Output (exe, dll) in einem Ordner im Programme-Verzeichnis iplatziert, dessen Pfad sich aus folgenden Teilen zusammensetzt: [ProgramFilesFolder] \ [Manufacturer] \ [ProductName]. Soll der Unterordner [Manufacturer] nicht verwendet werden, so wird der betreffende Eintrag einfach aus dem Pfad unter DefaultLocation (bei ausgewähltem Application Folder im Filesystem Editor) heraus gelöscht. Der eigentliche Pfad wird erst bei der Installation zusammengesetzt, abhängig davon, was der Anwender auswählt.

 

Jens Häupel - Registry Editor
Abb 1:

Visual Studio's Registry Editor mit Einträgen für ein Outlook Add-In

Noch mehr Hilfe kommt bei den Registry-Einträgen für Add-Ins (Abb. 1). Ja, es müssen leider noch welche geschrieben werden, weil Office in guter alter COM-Technologie programmiert worden ist und Erweiterungen auch in eben dieser erwartet. Aber keine Angst, um COM Interop braucht sich dank VSTO niemand mehr zu kümmern. Nur die Kommunikation mit Office, also welches Add-In für welches Programm bereit steht, lesen die Office-Programme aus der Registry – so wie auch ClassID, ProgID usw. Die gesamte Arbeit nimmt einem der automatisch ablaufende Wizard ab. Nun könnte allerdings eine Frage aufkommen: Alle Einträge stehen unter HKCU. Was ist bei einer per Machine Installation? Muß dann alles selbst eingetragen werden? Nein. Man kann den gesamten Registry-Baum von HKCU nach „Machine/User Hive“ v erschieben, was dazu führt, daß je nach ALLUSERS Property die Einträge entweder in HKCU oder HKLM geschrieben werden. So einfach ist es aber nicht.

Während Office 2003 noch systemweite VSTO Add-Ins erlaubt, werden diese von Office 2007 nicht mehr geladen. Office 2007 setzt das Flag für das Ladeverhalten (LoadBehavior) solcher Add-Ins zurück auf 0. Der Grund dafür ist in erhöhten Sicherheitsstandards zu suchen. Da der normale Anwender keinen Schreibzugriff auf HKLM hat, kann er auch das Ladeverhalten des Add-Ins nicht beeinflussen und damit auch nicht wählen, ob er es verwenden will oder nicht. Shared Add-Ins (COM Add-Ins, die direkt gegen IDTExtensibility2 gehen) sind davon nicht betroffen.

Office 2007 arbeitet enger mit VSTO zusammen als alle Versionen vorher und lädt VSTO-Add-Ins schneller, wenn es einen Manifest Key in der Registry findet. VSTO 2.0 hat 2 Keys: ManifestLocation und ManifestName, VSTO 2005 SE nur noch einen: Manifest. So kann Office auch zwischen beiden VSTO-Versionen unterscheiden.

+++ Fortsetzung in Teil 2 +++

Skip to main content