Bekanntlich sind Informationen direkt von der Quelle die besten, da nicht misinterpretiert. Andrew Whitechapel, Senior Program Manager im BizApps Team (der Wiege von VSTO) und maßgeblich am Design von VSTO beteiligt, schreibt über

• Wie kann man das Ladeverhalten von managed Add-Ins beeinflussen
• Licht im Dschungel der (VSTO-) Versionen
• Wie man dokumentzentrische Lösungen und Add-Ins integriert
• Mit VSTO v3 Add-Ins für Office 14 schreiben (for early adopters only)

Besonders für C# Entwickler interessant: Phil Hoff schreibt über die von ihm mitentwickelten Office Interop API Extensions (in den VSTO Powertools), einem Weg, wie man stark typisiert mit Office OM Parametern umgehen kann.

Kris Makey schreibt über Deployment-Themen in Bezug auf Office Integration mit VSTO und wie man mit der beteiligten Security umgeht.

Desweiteren hier noch ein paar Links zu VSTO 2008 (oder 3.0) Development:

VSTO Dokumentation: Englisch / Deutsch 

Samples and walkthroughs: Englisch / Deutsch 

Office Development whitepapers: Englisch

Im dotNet Magazin, Ausgabe 4/08 habe ich das Security-Modell und den Deployment-Mechanismus von VSTO 3.0 beschrieben. Da sicherlich nicht jeder (oder doch?) diese Ausgabe gelesen hat und die Länge des Artikels begrenzt war, hier noch ein paar Gedanken dazu.

VSTO 3.0 verwendet nach wie vor Code Access Security, wenn es um Add-Ins oder Dokumentzentrische Lösungen für Office 2003 geht. Zielen wir aber auf Office 2007, so können wir dieses Modell nicht mehr verwenden. Die verwendeten Manifeste (Application und Deployment Manifest) müssen digital signiert werden (ClickOnce Security Modell). Und dazu brauchen wir ein Digitales Zertifikat. Dieses sollte bei professionellen Lösungen von einer vertrauenswürdigen Internet Zertifikats-Authorität stammen (Verisign, Thawte, etc.) oder bei Unternehmenslösungen von einem im Unternehmen stehenden Zertifikatsserver (der MS Certificate Server ist im Windows Server enthalten).

Vor dem Deployment der eigentlichen Anwendung muß dann nur das zum Signieren benutzte Zertifikat auf den Clients bekannt gemacht werden, sprich ein sog. Trusted Publisher eingerichtet werden. Das Zertifikat der herausgebenden Authorität muß dabei im Root Certificate Store zu finden sein, damit eine Trust Chain aufgebaut werden kann. Damit kann eindeutig bestimmt werden, daß die zu installierende Anwendung von einem Herausgeber stammt, dem das System vertraut. Das ist nichts anderes als das, was größere Unternehmen mit einer intakten PKI (Public Key Infrastructure) heute schon bei der Verteilung von In-Haus-Anwendungen verwenden.

Doch, erstens kann/will nicht jeder Geld für Zertifikate ausgeben, zweitens hat nicht jeder die Infrastruktur für einen eigenen Zertifikatsserver und drittens sind die Sicherheitsanforderungen bei Einzel-PCs nicht die gleichen wie bei durch Administratoren verwalteten Netzwerken. Was also tun?

Die Manifeste von VSTO-Projekten in Visual Studio 2008 werden mit Zertifikaten signiert, die mit MakeCert.exe erzeugt werden (self-signed). Das sind universale Code Signing Zertifikate, denen aber ein wichtiger Teil fehlt: Die Manufacturer bzw. Publisher Information. Damit kann keine Trust Chain aufgebaut werden! Also doch ein Zertifikat kaufen?

Hier kommt eine Ausnahme ins Spiel. Die Inclusion List. Wird ein solches VSTO 3.0-Setup (ClickOnce Application) gestartet, fehlt die Trust Chain und ein Trust Prompt teilt dem Anwender mit, daß das verwendete Zertifikat nicht vertrauenswürdig ist (es wurde entweder ein vollständiges Zertifikat verwendet, aber der Herausgeber ist nicht in Trusted Root Certificates zu finden oder das Zertifikat wurde mit MakeCert erstellt und es fehlen die entsprechenden Infos). Weiterhin wird (nicht immer, aber dazu weiter unten im Text) gefragt, ob die Anwendung dennoch installiert werden soll.

Entscheidet sich der Anwender für ein Installieren, so wird neben den bekannten Infos auch ein Eintrag in die Inclusion List gesetzt. Diese Liste (HKCU\Software\Microsoft\VSTO\Security\Inclusion) enthält je einen Schlüssel mit zwei Werten (Public Key der Signatur und die URL zum Deployment Manifest) für eine VSTO 3.0 Lösung. Solange sich die Signatur der Anwendung nicht ändert, wird Ihr (auch nach Updates) vertraut.

In verwalteten Umgebungen, wo ein Netzwerk-Administrator sich darum kümmert, wer was darf und warum, ist dieses Verhalten nicht erwünscht und kann auch abgeschaltet werden. Auch bei Anwendungen, die aus unsicheren Zonen wie dem Internet kommen, könnte das ein Problem werden.

Aus diesem Grund kann das TrustPrompt-Verhalten separat gesteuert werden. Dazu wird in der Registry unter HKLM\SOFTWARE\Microsoft\.NETFramework\Security\TrustManager\ ein Key PromptingLevel angelegt und für die gewünschte Zone (siehe Tabelle) der Wert auf Enabled, AuthenticodeRequired bzw. Disabled gesetzt werden. (An dieser Stelle war die Erklärung im dotNet Magazin etwas zu kurz gekommen)

Enabled ist klar, TrustPrompts sind erlaubt.

AuthenticodeRequired bedeutet, dass Trust Prompts erlaubt sind, wenn:

• ein Zertifikat mit einer bekannten Identität (Publisher Informationen) verwendet wird (was ein in Visual Studio mit makecert.exe selbst erzeugtes Zertifikat nicht besitzt)
• dieses Zertifikat nicht im Trusted Publisher Store zu finden ist
• das Zertifikat des Herausgebers (bspw. das des eigenen Zertifikatsservers) im Trusted Root Store liegt

In diesem Fall spricht man von sog. Friendly Trust Prompts, da sie das Installieren erlauben:

Ein Klick auf "More Information ..." enthüllt Details:

Man kann also schon anhand des Icons im Dialog gewissse Rückschlüsse ziehen. Die Publisher Informationen sind bei einem Self-Cert (also mit MakeCert erstelltem Zertifikat nicht zu sehen, weil nicht vorhanden.

Bei Disabled besteht keine Chance des Umgehens. Nur vertrauenswürdige Zertifikate (mit vollständiger Trust Chain, also Trusted Publisher und Trusted Root Zertifikate vorhanden und gültig) sind erlaubt. Das betrifft auch schon vorhandene Inclusion List Einträge, die in diesem Fall ignoriert werden, da die Zertifikatsauswertung Priorität vor der Inclusion List besitzt.

Sind diese Voraussetzungen nicht gegeben, so erhält man ein sog. Unfriendly Trust Prompt, nur um zusagen: Pech gehabt, die Lösung kann nicht installiert werden:

Auch hier erhüllt ein Klick aud Details die Hintergründe:

Einen Ausweg stellt die Aufnahme des entsprechenden (Installations-)Pfades in die Liste der TrustedSites sein. Dafür gibt es einen eigenen PromptingLevel-Eintrag, der i.d.R. auf Enabled gesetzt sein dürfte. Das funktioniert aber nur, wenn der Pfad nicht unter UntrustedSites gelisted ist.

Wurde dagegen das PromptingLevel nach der Installation einer mit einem nicht vertrauten Zertifikat signierten Lösung (dabei wurde der TrustPromt positiv bestätigt) von Enabled auf AuthenticodeRequired oder Disabled geändert, so läuft die Lösung trotzdem, da die Prüfung während der ClickOnce Installation abläuft und nicht beim Start der Anwendung.

Obwohl der Key PromptingLevel i.d.R. nicht vorhanden ist, sind folgende Werte aktiv:

Visual Studio 2008 selbst legt übrigens für jedes VSTO-Projekt (für Office 2007) einen Eintrag in der Inclusion List an. (Vorsicht also bei Testen von ClickOnce Deployment für Öffice Lösungen auf der Entwickler-Maschine, es müssen nach dem Publish-Prozess zuerst die Add-In Einträge für Office und der Eintrag in der Inclusion List entfernt werden!)

Außerdem überprüft VS auch, ob eine intakte Trust Chain für nicht selbst generierte Zertifikate besteht und bricht das Kompilieren ab, wenn das nicht der Fall ist. (Beispiel: Code Signing Certifikat im Trusted Publisher Store, aber kein Trusted Root vorhanden)

Tools:

Zum Handhaben der Zertifikate sollte man die Management Console (MMC) mit dem Snap-In Zertifikate verwenden. In gewissem Umfang kann auch der Browser (Tools - Options - Content - Certificates) verwendet werden, jedoch zeigt dieser nicht alle Stores an.

Übrigens, wenn beim Signieren ein TimeStamp (offizieller Zeitstempel einer bekannten Internet Authorität, TimeStamp Server) verwendet wird, dann laufen Ihre Lösungen auch noch nach Ablauf des Gültigkeitsdatums des Zertifikates, da der Zeitpunkt des Signierens innerhalt des Gültigkeitzeitraums lag und das auch nachgewiesen werden kann (anhand des TimeStamps). Ansonsten müssen Zertifikate nach Ablauf erneuert werden. Er handelt sich dabei um kein komplett neues Zertifikat, sondern es enthält Informationen des ursprünglich erstellten. Somit müssen bei erneuerten Zertifikate die einmal verteilten Lösungen nicht erneut signiert werden.

Fazit:

In der Regel wird sich der Entwickler nicht um die PKI (Public Key Infrastructure) kümmern, da dies von Administratoren erledigt wird. Erstens ist aber gut zu wissen, wie es funktioniert und zweitens kommt es wahrscheinlich schon vor, dass Admin und Entwickler eine Personalunion bilden.

... behaupten nicht wenige außerhalb der MS-Welt. Und denken dabei an die Welt von Windows und Office. Zugegeben, Innovationen in diesem Bereich - vielleicht mal von den Ribbons abgesehen - sind nicht so offensichtlich. Doch Microsoft ist auch in anderen Bereichen tätig, beschäftigen wir doch 600+ Wissenschaftler bei MS Research, die ständig auf der Suche nach Neuem sind.

Wer sich mit Fotografie beschäftigt, wird sich vielleicht schon einmal mit HDR (High Dynamic Range) Imaging oder dem Zusammensetzen von Einzelbildern zu Pamoramas (stitching) beschäftigt haben und sollte dann die Image Based Realities von Microsoft Research nicht missen. Das Stitching Tool sollte man unbedingt mal ausprobieren

PhotoSynth und DeepZoom sind weitere innovative Technologien, die Verknüpfungen von statischen Images zu dreidimensionalen Bildräumen sowie eine Zoom-Experience erlauben, wie sie bisher nicht bekannt waren. Doch, schauen Sie selbst. Blaise Aguera y Arcas (Software Architekt bei Microsoft Live Labs und Architekt von SeaDragon sowie Co-Author von PhotoSynth) präsentiert beide Technologien hier:

Seit kurzem gibt es eine eigene Webseite bzgl. Fragen zu Microsoft Terminologie, und zwar für über 90 Sprachen! Das Microsoft Sprachenportal lädt ein zur Terminologiesuche über alle Produkte. Sie können sprachabhängige Style-Guides herunterladen oder auch Feedback geben. Zudem erfahren Sie neues zum Thema im dazugehörigen Blog von einer Microsoft-Terminologin (Ich wußte bisher nicht, daß es so eine Job-Bezeichnung überhaupt gibt)

Seit Version 3.5 des .NET Frameworks ist es möglich, Dateierweiterungen auch bei ClickOnce Deployment mit dem zu verteilendem Programm zu verbinden. Aber wie ist das möglich, findet sich doch in Visual Studio kein Hinweis dazu?

Vorbedingungen für die Anwendung sind:

• FullTrust anfordern
• Offline verfügbar sein
• als normale Windows Anwendung funktionieren (also keine im Browser laufende WPF App)

Benötigte Tools:

• Mage.exe (.NET Framework Manifest Generation Tool)

Auszuführende Schritte:

Nach dem normalen Publish-Prozess öffnen wir das Application Manifest MyApp.exe.manifest in Visual Studio und fügen vor der PublisherIdentity die Informationen zur zu registrierenden Dateierweiterung ein:

<fileAssociation extension=".abc" description="My Tester App" progid="abc.Document" defaultIcon="Camera.ico" xmlns="urn:schemas-microsoft-com:clickonce.v1" />

Achten sollte man darauf, dass das angegebene Icon auch mit im Deployment Prozess integriert wurde und dessen Name korrekt ist (case sensitiv).

Das Ganze wird wieder abgespeichert und muß jetzt erneut signiert werden, da durch die Änderung der Hash nicht mehr stimmt.

Das Application Manifest MyApp.exe.manifest kann gleich nach dem Öffnen in Mage wieder gespeichert werden. Dabei wird dach dem digitalen Zertifikat gefragt, welches entweder aus dem lokalen Store oder von einer Datei geholt werden kann.

Das Deployment Manifest MyApp.application erfordert einen Eingriff. Nach dem Öffnen in Mage wird unter Application Reference das eben signierte Application Manifest ausgewählt. Dadurch wird erstens der Pfad angepaßt (Vorsicht: relativer Pfad!) und zweitens ein Hash ermittelt und in das Deployment Manifest eingetragen. Danach wird wiederum beim Speichern signiert.

Wenn jetzt die Anwendung per ClickOnce installiert wird, wird auch die File Extension registriert. Beim Entfernen wird die Verbindung zur Anwnedung wieder entfernt.

Vorsicht ist unter Windows Vista geboten. Dort kann es zu jeder registrierten Dateierweiterung mehrere Anwendungen geben, die über einen UserCoice Eintrag in der Registry gesteuert werden. Wenn also Ihre registrierte Erweiterung scheinbar nicht akzeptiert wird, so kann das daran liegen, daß sie bereits mit einem anderen Programm verbunden ist und der Anwender diese Verbindung bereits genutzt hat (Doppelklick auf eine Datei mit einer solchen Erweiterung). In diesem Fall holt ein Rechtsklick auf die Datei die Eigenschaften dieser auf den Bildschirm und erlaubt eine Änderung der Zuordnung.

Das mehr als eine Anwendung zugeordnet ist, erkennt man auch, wenn per Rechtsklick auf die Datei Öffnen mit ... aufgerufen wird:

Wenn die Anwendung über die File Extension aktiviert wird, wird der Auto Update Mechanismus trotzdem verwendet. Es kann also sein, daß bei einem Doppelklick auf eine Datei ein Update der Anwendung angeboten wird.

Mit einer ClickOnce-Anwendung können so bis zu 8 Dateierweiterungen registriert werden.

Wie alles bei ClickOnce werden die Änderungen auf einer per-User Basis durchgeführt.

Sollte eine andere Anwendung inzwischen die Zuordnung geändert haben, so erkennt ClickOnce das beim Deinstallieren und beläßt es dabei.

Am Dienstag, dem 8. April, wurden mehr als 14.000 Seiten an Dokumentation (vorläufige Versionen) zu in Office-Anwendungen bzw. in Windows selbst verwendeten Protokollen veröffentlicht. Dazu gehören Anwendungen wie Office 2007, SharePoint Server 2007 und Exchange Server 2007.

Jeder, der das möchte, hat nun (kosten-) freien Zugriff darauf.

Unter den Protokollen sind z.B. die für Microsoft Error Reporting, für File bzw. Data Access oder Document Management Protokolle aus der Office-Familie. Oder aber auch Windows Protokolle wie Active Directory Schema Informationen bzw. Application Services and .NET Framework Protokolle.

MSDN Open Protocol Specifications pages

Hin und wieder werde ich gefragt, ob man mit VSTO auch Tabellenfunktionen für Excel schreiben kann. Nun, bislang kann man das nicht. Allerdings kann man mit etwas COM Interop das Ganze als Excel Add-In (Vorsicht, nicht COM Add-In) laufen lassen. Wie das geht, will ich im Folgenden mal beschreiben.

Als allererstes muß natürlich in Visual Studio eine einfache Klassenbibliothek angelegt und diese für COM sichtbar gemacht werden. Wichtig dabei ist, dass das COM Interface vom Typ AutoDual ist, sonst sieht Excel die Klasse nicht. Da bei der COM Registrierung mittel Regasm kein Programmable Key geschrieben wird, wir den aber brauchen, müssen wir uns selbst darum kümmern, dass der geschrieben wird. Dafür sind die beiden Methoden RegistrationMethod und UnregistrationMethod zuständig.

Nun ist es relativ einfach, Funktionen mit skalaren Parametern wie integer oder double zu implementieren:

Schwieriger wir es, wenn der Inhalt eines Arrays durchsucht werden soll. Normalerweise würden wir das so machen:

Das funktioniert aber nicht. Da ein Range Objekt in Excel als ein einziges COM Objekt (System.__ComObject) übergeben wird, müssen wir die Werte der einzelnen Zellen herausholen und ein Array erzeugen, welches am besten auch noch 0-basiert ist. Diese Konvertierung wird der eigentlichen Funktion vorgeschaltet:

Dazu kommt noch die Behandlung sog. flüchtiger Funktionen. Das sind solche, die bei gleichen Parameterwerten zu verschiedener Zeit unterschiedliche Ergebnisse liefern, wie z.B. now().

Sind diese im eigenen Code enthalten, müssen wir die Hostanwendung (also Excel) darauf aufmerksam machen (Volatile-Methode). Das führt dann dazu, dass nach Eingabe der Funktion bei jedem Neuberechnen der Tabelle auch diese Funktion berechnet wird. Anderenfalls denkt Excel - da sich die Eingabewerte ja nicht verändert haben - der Rückgabewert wäre konstant.

Wir benötigen dafür einen Zeiger auf die aktuelle Instanz von Excel, weswegen wir IDTExtensibility implementieren müssen und deshalb eine Referenz auf die Extensibility Library und - wegen der Typreferenz (Excel.Application) - die Excel PIA setzen müssen. In dessen OnConnection Event bekommt man diese Instanz übergeben. Dort speichern wir uns den Zeiger in einer lokalen Property. Alle anderen Events des IDTExtensibility Interfaces brauchen wir nicht zu befüllen, müssen diese aber implementieren und die Standard-Inhalte entfernen (Throw Exception, hier im Beispiel nicht angegeben)

Nach dem Kompilieren muß die Assembly nur noch registriert werden: regasm /codebase ExcelExtender.dll
(unter Vista die Console im Admin-Mode starten)

Und am Ende das Add-In Excel bekannt machen:

Danach können wir die Erweiterungsfunktionen auf der Maschine, auf der die Erweiterungsbibliothek registriert wurde verwenden

Weitere Hinweise finden Sie in den Teilen eins, zwei und drei einer 3-teiligen Serie von Shahar Prish.

Der Kollege ist Software Architect im Excel Services Team in Redmond und schreibt darin über User Defined Functions, die sowohl in Excel Services als auch auf dem Client verwendet werden können. Den Excel Services-Anteil kann man in unserem Kontext einfach ausblenden.

Wer sich mal die Systemanforderungen für VSTO 2005 SE angesehen hat (macht das überhaupt jemand?), wird festgestellt haben, dass da auch die Standard Version von Office 2003 drin steht. Wie denn das? Hat Microsoft nicht immer behauptet, es gehe erst ab Professional? Jein. Früher gab es nur dokumentzentrische Erweiterungsmöglichkeiten (bis VSTO 2.0) und die funktionierten wegen der in der Standard-Version von Office 2003 fehlenden XML-Unterstützung erst ab der Pro-Version.

VSTO 2005 SE brachte aber applikationsweite Add-Ins, und die sind völlig unabhängig von einer XML-Unterstützung. Also kann man ab VSTO 2005 SE auch Add-Ins für Office 2003 Standard schreiben. Bei Office 2007 wurde die Standard-Limitierung beseitigt und es geht sowieso.

Doug Mahugh, Program Manager bei Microsoft in Redmond, hat eine umfangreiche Liste an Ressourcen zu Open XML zusammengestellt. Sehr hilfreicht für jeden, der damit arbeitet oder erst mal anfangen will.

ich habe mir in den letzten Tagen die Zeit genommen, wichtige Features von VSTO im Video zu demonstrieren. Vier Video-Demos sind jetzt auf MSDN freigegeben:

Visual Studio Tools for Office (Teil 1 von 4) - Outlook Custom Form Regions mit VSTO 3.0
Dauer: 51 min

Visual Studio Tools for Office (Teil 2 von 4) - Office Client UI Extensibility
Dauer: 50 min

Visual Studio Tools for Office (Teil 3 von 4) - Deployment & Security
Dauer: 54 min

Visual Studio Tools for Office (Teil 4 von 4) - VSTO - VBA Interop: VBA mit VSTO verwenden und erweitern
Dauer: 37 min

Haben Sie weitere Ideen bzgl. für Video-Tutorials im Themenbereich VSTO? Ich freue mich über eine Rückmeldung.

Von den 87 National Body Members (stimmberechtigten Ländern) unterstützen 87% die ISO/IEC Standardisierung, was ein ganzen Stück über der mit 75% festgesetzten Grenze für formale Akzeptanz unter ISO und IEC Regeln liegt. Ebenfalls unterstützen 75% der P-Members die Standardisierung (die Grenze liegt hier bei 2/3 aller Stimmen).

Jan van den Beld (former Secretary General of Ecma International): The value of standardization bodies

-------------------------------------------------

Brian Jones

ECMA Statement

Presseerklärung

--------------------------------------------------

Open XML Resources for Developers

[kein Aprilscherz]