Open XML, VSTO, Deployment, .NET und anderes : .NET Dev mit Office

Was hat die Wiener Oper mit VSTO zu tun?

jensha — Wed, 25 Mar 2009 14:41:02 GMT

Eigentlich nichts, aber …

… am 8. Mai findet in Wien der Office VSTO Community Day statt. Dabei geht es um Office Business Applications. Die Veranstaltung wird von Lars Keller und Mario Meir-Huber geführt.

Die Themen sind:

Einführung in die VSTO
OpenXML: Das neue Office Format
VSTO Deployment
Sharepoint Workflows und Integration
Interaktionen in der "Office-Welt" mit .NET
Office plus Services

… Sie könnten einen Besuch des Community Days mit einem solchen der berühmten Oper verbinden. Müssen Sie das? Nein, aber wann würden Sie es sonst tun?

… Außerdem könnten Sie gleich noch das Microsoft Innovation Center (MIC) kennen lernen.

--> VSTO TaskForce

VSTO lebt (auf)

jensha — Wed, 04 Mar 2009 15:47:02 GMT

Nun gibt es endlich ein deutschsprachiges Portal, auf dem die Fäden der Entwicklung von Office Business Anwendungen (OBA) zusammengeführt werden.

Lars Keller und Mario Meir-Huber haben die VSTO TaskForce aus dem Boden gestampft.

Wenn auch Sie Infos zu Office-Entwicklung, SharePoint und VSTO haben und regelmäßig darüber bloggen, kann Ihr Blog dort aggregiert werden und viele andere haben etwas davon. Da es ein Community-Projekt ist, kann es nur erfolgreich werden, wenn möglichst viele mithelfen.

Wenn der Kreis der Mitwirkenden groß genug ist, kann man sicher auch über ein deutschsprachiges Forum nachdenken. Denn das amerikanische Forum von Microsoft ist nun mal in englisch und es ist nicht jedermanns Sache, Fragen präzise in Englisch zu stellen.

Ich wünsche jedenfalls viel Erfolg.

VSTO NEXT

jensha — Fri, 14 Nov 2008 15:00:00 GMT

Auf der in Los Angeles Ende Oktober stattgefundenen Professional Developers Conference wurden ein paar Geheimnisse um die nächste Version von VSTO gelüftet. Eigentlich heißt es ja nicht mehr VSTO, da schon seit VS 2008 VSTO Bestandteil von Visual Studio ist, aber die Abkürzung hat sich seit der Einführung verbreitet und viele können sich etwas darunter vorstellen.

Was wird also an Neuem kommen?

Zum einen war es bisher ein Problem, wenn mehr als ein Projekt (oder besser Einzellösung) an der gesamten VSTO Solution beteiligt war, alle DLL per ClickOnce zu verteilen. Ich meine damit nicht, dass verschiedene Assemblies verwendet werden, um eine Solution (z.B. eine Outlook Form Region) zu verteilen, sondern dass eine Lösung mehrere Entry Points enthält (z.B. mehrere Add-Ins für die gleiche oder gar unterschiedliche Office Anwendungen).

Dafür mußte bisher entweder ein MSI Package gebaut oder alle Add-Ins einzeln verteilt werden. Dank Multi-Project Deployment gehört das der Vergangenheit an. Es können im Zuge eines Update-Prozesses auch einzelne Add-Ins aus dem Gesamt Package entfernt oder dazu hinzugefügt werden. Um das zu erreichen wurde die Möglichkeit geschaffen, mehrere Entry Points im Application Manifest zu definieren. In der Registry würde das Ganze dann so aussehen:

HKCU\Software\Microsoft\Office\Excel\AddIns\MyChartingAddIn\

manifest = MyProject.vsto|id=MyChartingAddIn

HKCU\Software\Microsoft\Office\Excel\AddIns\MyCalculationAddIn\

manifest = MyProject.vsto|id=MyCalculationAddIn

Post Deployment Custom Actions

Hin und wieder ist es nötig, innerhalb des ClickOnce Processes eigene Aktionen auszuführen. Was im Windows Installer als Custom Action bekannt ist, wird nun auch (limitierter Form) bei ClickOnce möglich sein. Limitiert deshalb, weil ClickOnce im User Context ausgeführt wird (MSI läuft unter LocalSystem). Aus diesem Grunde sind die Aktionen auch auf alles limitiert, was der angemeldete Benutzer darf. Process Elevation ist nicht erlaubt. Ausgeführt wird der eigene Code unmittelbar nachdem die Anwendung in den ClickOnce Download Cache geladen wurde. Basierend auf dem Installationsstatus (InitialInstall, UnInstall, Update, Rollback) kann die jeweilige Aktion definiert werden. Ebenso wie bei den Custom Actions des MSI sollte man auch hier darauf achten, die Änderungen in der entgegen gerichteten Action wieder zurück zu nehmen.

No more PIA Mode

Primary Interop Assemblies müssen in der nächsten Version von VSTO nicht mehr unbedingt mit verteilt werden, da der Compiler in der Lage sein wird, die Definitionen der verwendeten Typen aus den PIAs im Code einzubetten (Type embedding).

Das ist eine generelle Funktionaliät des C# 4.0 Compilers und nicht unbedingt VSTO-bezogen.

Eine weitere Änderung des C# Compilers ist die Fähigkeit, optionale und benannte Parameter zu unterstützen (VB-Programmierer dürfen jetzt lachen). Also statt des wirklich Schrecklichen:

      Excel.Workbook wb = xlApp.Workbooks.Open(FilePath, System.Type.Missing, System.Type.Missing,
                                               System.Type.Missing, System.Type.Missing,
                                              System.Type.Missing, System.Type.Missing,
                                             System.Type.Missing, System.Type.Missing,
                                             System.Type.Missing, System.Type.Missing,
                                             System.Type.Missing, System.Type.Missing,
                                             System.Type.Missing, System.Type.Missing);

würde es so aussehen:

Excel.Workbook wb = xlApp.Workbooks.Open(FilePath);

oder bei mehreren verwendeten Parametern:

Excel.Workbook wb = xlApp.Workbooks.Open(Filename: FilePath, Password: myPassword, Local: true);

Anders Hejlsberg meinte, er hat endlich den vielen Anfragen nach diesem Feature nachgegeben.

Ressourcen vom BASTA!-Chalk Talk

jensha — Fri, 26 Sep 2008 18:00:27 GMT

Hier gibt's nachträglich noch meine Mindmap vom VSTO Deployment, die ich auf der Basta! gezeigt hatte. Mit ein Klick auf das Bild gibts eines, wo Sie auch was lesen können. Desweiteren meine Notizen dazu im Stichwort-Word-Format.

SmartTags für alle

jensha — Fri, 05 Sep 2008 15:39:00 GMT

Visual Studio 2008 / .NET 3.5 Service Pack 1 brachte auch für VSTO ein paar Updates. Eines zählt zu meinen Lieblings-Features: SmartTags. Bisher waren diese nur für dokumentzentrische Anwendungen verfügbar, also an ein bestimmtes Dokument oder eine Vorlage gebunden. Klar, diese Einschränkung hatte auch seine Vorteile. So konnte man viel aggressiver an die Erkennung von Mustern oder Begriffen (sog. Terms) gehen, da der Gültigkeitsbereich des SmartTags sehr stark eingeschränkt (nämlich das eine Dokument) war.

Nun sind diese Objekte und Klassen auch in einem zentralen Add-In verfügbar. Hier ein Beispiel, welches eine Liste von Begriffen und darüber einen SmartTag mit einer Action definiert. Als Action dient eine einfache Web-Suche auf Wikipedia.

using Word = Microsoft.Office.Interop.Word;
using Office = Microsoft.Office.Core;
using VSTO = Microsoft.Office.Tools.Word;
using System.Text.RegularExpressions;
using System.Windows.Forms;

namespace AppLevelSmartTag4AllDocs
{
  public partial class ThisAddIn
  {
    private VSTO.SmartTag myTermsSmartTag = null;
    private string[] terms = { "Luke", "Leia", "Han", "Anakin", "Jacen", "Jaina", "Vader", "Wedge" };
    private VSTO.Action acSearchWikipedia;

    private void ThisAddIn_Startup(object sender, System.EventArgs e)
    {
      myTermsSmartTag = new VSTO.SmartTag("SmartTags.jensha.net/StarWars#CharacterSample", "Star Wars Character Sample");
      foreach (string t in terms)
        myTermsSmartTag.Terms.Add(t);

      acSearchWikipedia = new VSTO.Action("Star Wars///Get Info from Wikipedia");
      acSearchWikipedia.Click += new Microsoft.Office.Tools.Word.ActionClickEventHandler(acSearchWikipedia_Click);

      myTermsSmartTag.Actions = new VSTO.Action[] { acSearchWikipedia };

      VstoSmartTags.Add(myTermsSmartTag);
    }


    void acSearchWikipedia_Click(object sender, Microsoft.Office.Tools.Word.ActionEventArgs e)
    {
      string searchText = "%22Star Wars%22 %22" + e.Text + "%22";
      System.Diagnostics.Process.Start("http://en.wikipedia.org/wiki/Special:Search?search=" + searchText);
    }
  }
}

Der so definierte SmartTag gilt nun für alle geöffneten und noch zu öffnenden bzw. neuen Dokumente. Aber es geht noch besser. Was ist, wenn ich den Gültikeitsbereich einschränken will? Wenn nur bestimmte Dokumente den SmartTag bekommen sollen? Auch das läßt sich bewältigen. Über neue Extensions (Microsoft.Office.Tools.xxxx.Extension) kann die benötigte Funktionalität - nämlich der Zugriff auf die lokalen Objekte des Dokuments - erreicht werden. Die Methode heißt GetVstoObject() und liefert hier den Zugriff auf die SmartTag Collection.

Da der SmartTag nun nicht mehr automatisch alle Dokumente umfaßt, müssen wir uns selbst um das Hinzufügen neuer Dokumente kümmern. Also jedes Mal, wenn ein Dokument geöffnet oder neu angelegt wird (Office Events abfangen), prüfen wir, ob das Dokument in unser Muster paßt (hier nicht implementiert) und fügen bei positiver Überprüfung den SmartTag der SmartTag Collection des Dokuments hinzu.

using Microsoft.Office.Tools.Word.Extensions;
...

namespace AppLevelSmartTag4AllDocs
{
  public partial class ThisAddIn
  {
    ...

    private void ThisAddIn_Startup(object sender, System.EventArgs e)
    {
      foreach (Word.Document doc in this.Application.Documents)
        AttachSmartTag(doc);

      this.Application.DocumentOpen += 
        new Word.ApplicationEvents4_DocumentOpenEventHandler(WordApp_DocumentOpen);
      ((Word.ApplicationEvents4_Event)Application).NewDocument += 
        new Word.ApplicationEvents4_NewDocumentEventHandler(WordApp_NewDocument);
    }


    void WordApp_NewDocument(Microsoft.Office.Interop.Word.Document doc)
    {
      AttachSmartTag(doc);
    }


    void WordApp_DocumentOpen(Microsoft.Office.Interop.Word.Document doc)
    {
      AttachSmartTag(doc);
    }


    private void AttachSmartTag(Word.Document doc)
    {
      if (myTermsSmartTag == null) 
      {
        myTermsSmartTag = new VSTO.SmartTag("SmartTags.jensha.net/StarWars#CharacterSample", "Star Wars Character Sample");
          foreach (string t in terms)
          {
            myTermsSmartTag.Terms.Add(t);
          }
      
          acSearchWikipedia = new VSTO.Action("Star Wars///Get Info from Wikipedia");
          acSearchWikipedia.Click += new Microsoft.Office.Tools.Word.ActionClickEventHandler(acSearchWikipedia_Click);

          myTermsSmartTag.Actions = new VSTO.Action[] { acSearchWikipedia };
      }

      doc.GetVstoObject().VstoSmartTags.Add(myTermsSmartTag);
    }

Im Beispiel wurde mit der Terms Liste gearbeitet, die allerdings nur aus einem Wort bestehende Begriffe erkennt, da der in Word eingebaute Tokenizer den Text in entsprechende Tokens zerlegt. Werden Begriffe benötigt, die aus mehreren Worten bestehen oder einem bestimmten Muster unterliegen, so kann mit Regular Expressions gearbeitet werden.

GetVstoObject() hat noch andere Vorteile: Man kann so auf die im Dokument eingebetteten Objekte (HostItems, wie z.B. ein ListObject in Excel) zugreifen.

RibbonX kennt .NET Images

jensha — Fri, 18 Jul 2008 14:10:55 GMT

Das ist irgendwie total an mir vorbei gegangen. Während in der Beta (VS 2008 Office Integration) bei dynamisch befüllten Ribbon Controls:

<dropDown id="MyDropDown"
          getItemID="getDDItemID"
          getItemCount="getDDItemCount"
          getItemLabel="getDDItemLabel"
          getItemImage="getDDItemImage"
          onAction="onDDAction">
</dropDown>

immer noch die Images als COM Struktur IPictureDisp übergeben:

public stdole.IPictureDisp getDDItemImage(Office.IRibbonControl control, int index)
{
   MemoryStream iconStream = new MemoryStream(...);
   return ImageConverter.ImageToPictureDisp(Image.FromStream(iconStream));
}

und dann datürlich eine Umwandlungsroutine geschrieben werden mußte, die Image in IPictureDisp konvertiert:

internal class ImageConverter : System.Windows.Forms.AxHost
{
  public ImageConverter() : base(string.Empty) { }

  static public stdole.IPictureDisp ImageToPictureDisp(Image image)
  {
    return (stdole.IPictureDisp)GetIPictureDispFromPicture(image);
  }

  static public stdole.IPictureDisp IconToPictureDisp(Icon icon)
  {
    return ImageToPictureDisp(icon.ToBitmap());
  }
}

kann jetzt das Image direkt übergeben werden:

public Image getDDItemImage(Office.IRibbonControl control, int index)
{
   MemoryStream iconStream = new MemoryStream(...);
   return Image.FromStream(iconStream);  
}

Leider geht das nicht mit Icons. Also wer schön freigestellte Icons verwendet, wird nach wie vor die Umwandlungsroutine nutzen müssen (Was nicht wirklich viel mehr Aufwand darstellt).

Upgrade but don't upgrade

jensha — Mon, 30 Jun 2008 14:03:47 GMT

Stellen Sie sich vor, Sie haben ein VSTO 2005 SE Projekt mit Visual Studio 2005 und wollen auf Visual Studio 2008 umsteigen. Das Projekt stellt eine Erweiterung für Office 2003 dar, Sie haben auf der Entwicklermaschine aber schon Office 2007 installiert. Wenn Sie dieses Projekt nun in VS 2008 öffnen, bekommen Sie zwar die neue Code Basis, aber das Add-In zielt nun auf Office 2007 und nicht mehr auf 2003. Wollten Sie das so? Wenn ja, fein - wenn nicht, dann kannten Sie die folgende Option nicht.

In den Optionen von VS 2008 findet sich eine Rubrik Office Tools, die genau dieses Verhalten steuern kann. Wie im Bild zu sehen, kann das Verhalten bei Projektupdates beeinflußt werden:

Damit kann nach wie vor gegen die gleiche Version von Office entwickelt werden, obwohl diese gar nicht mehr installiert ist.

Anthony Crider, Software Design Engineer im BizApps Team, hat darüber einen Blogeintrag geschrieben.

Übrigens kann man so auch ein neues Projekt für eine auf der Entwicklungsmaschine nicht vorhandene Office-Version anlegen. Das Deaktivieren der o.g. Option verhindert, daß beim nächsten Öffnen das Projekt auf die neue Office-Version konvertiert wird.

Visual Studio 2008 Extensions for SharePoint

jensha — Mon, 09 Jun 2008 13:45:49 GMT

Endlich kann auch mit Visual Studio 2008 Sharepoint Entwicklung betrieben werden. Die Erweiterungsbibliotheken und einiges mehr stehen zum Download bereit.

Visual Studio 2008 extensions for SharePoint

Provides project templates for SharePoint artifacts and F5 solution debugging on Visual Studio 2008.

Download

Visual Studio extensions for SharePoint User Guide

150 Pages of User Guide for the Visual Studio extensions for SharePoint including tool descriptions and step by step how to guide’s for each project template including workflow.

Download

A getting started with SharePoint flyer

One side is for IT Professionals and the other side is for developers.

Download

SharePoint Development for .NET Developers

A new landing page for SharePoint developers with lots of new content. Everything from videos and online MSDN Virtual Labs to sample PPTs and Demos for presentations.

And don’t forget the SharePoint Developer and Programming Forum is resourced so customers can get answers.

VSTO 3.0 / Office 2007: Whitepaper für MSI-Deployment

jensha — Fri, 30 May 2008 16:29:37 GMT

Lange hat's gedauert, aber nun ist das Whitepaper verfügbar. Darin wird erklärt, was alles zu tun ist, um VSTO 3.0 Lösungen für Office 2007 in einem Windows Installer Package zu verteilen.

Teil 1 und Teil 2

Inhalt:

You can develop a Visual Studio Tools for the Office system 3.0 solution for the 2007 Microsoft Office system, and deploy the solution by using a Visual Studio 2008 Setup project to create a Windows Installer package. The discussion includes steps for deploying a simple add-in, including additional files and components, and trusting the solution. This applies to both application-level add-ins and document-level solutions.

VSTO 3.0 Add-Ins für alle User installieren

jensha — Fri, 09 May 2008 17:20:42 GMT

Das Office 2007 Security Modell erlaubt es nicht, unter HKLM registrierte Managed Add-Ins zu verwenden. Was nicht heißt, dass mit einem Trick das Ganze nicht dennoch erreicht werden kann. Misha Shneerson, Senior Software Design Engineer im Microsoft BizApps Team, hat die notwendigen Aspekte in seinem Blog (Teil 1, Teil 2, Teil 3) beschrieben. Ich will mir hier die Zeit nehmen und das Ganze etwas erläutern.

Die Basis ist ein Registry-Replikations-Mechanismus von Office, durch welchen bestimmte Einträge von HKLM nach HKCU repliziert werden, wenn eine der Office Anwendungen gestartet wird.

Definiert werden diese Einträge unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\User Settings mittels eines Create bzw. Delete Keys.

Ein Beispiel:

Ein Add-In für Excel 2007 wird hier registriert (ich gehe davon aus, dass die Manifests digital signiert wurden und eine Trust Chain auf der Zielmaschine existiert (siehe hier):

HKEY_CURRENT_USER\Software\Microsoft\Office\Excel\Addins\MyAddIn

Die erforderlichen Einträge wären:

Name	Type	Value
Description	REG_SZ	Ein Add-In für Excel ...
FriendlyName	REG_SZ	MyAddIn
LoadBehavior	DWORD	3
Manifest	REG_SZ	C:\\Program Files\\MyCompany\\MyAddin.vsto\|vstolocal

Um jeden an der Maschine angemeldeten Benutzer in den Genuß des Add-Ins kommen zu lassen, wird dieser Pfad im Prinzip auf die UserSettings von Office 2007 in HKLM "kopiert". Der gesamte Pfad würde dann so aussehen:

HKEY_LOCAL_MACHINE
   SOFTWARE
      Microsoft
         Office
            12.0
               User Settings
                 MyCompany_MyAddIn
                     Create
                        Software
                           Microsoft
                              Office
                                 Excel
                                    Addins
                                       MyAddIn

Unter MyAddIn stehen dann die in der o.g. Tabelle angegebenen Werte.

Nicht genug

Das reicht aber noch nicht. Repliziert wird der Pfad nur, wenn eine vorhandene Count Property (DWORD) auf dem im obigen Pfad fett formatierten Key (MyCompany.MyAddIn) gefunden wird und deren Wert vom Wert derselben im Ziel-Hive der Registry (HKCU) abweicht.

Der Wert am Zielort wird unter HKCU\Software\Microsoft\Office\12.0\User Settings\MyAddIn geführt. Das wird getan, um nicht bei jedem Start die Replikation durchzuführen, sondern nur bei Änderungen. Deshalb muß auch diese Count Property nach dem Deinstallieren erhalten bleiben. Am besten. man zählt bei jeder Änderung per Custom Action den Wert um eins hoch. Der Wertebereich eines DWords sollte für einige Zeit ausreichen.

Da die Installation mittels MSI stattfinden sollte, müssen einige Dinge beachtet werden:

Der unter Manifest angegebene Pfad muß so aussehen: [TARGETDIR]MyAddin.vsto|vstolocal
Der MSI setzt den ausgewählten Zielpfad automatisch ein.
Der Create Key muß mit dem Flag DeleteAtUninstall versehen sein, damit er wieder entfernt wird.
Beim Deinstallieren muß ein Delete Subkey geschrieben werden, der dafür sorgt, daß beim nächsten Start der Hostapplikation die Registrierung des Add-Ins aufgehoben wird. Der sieht vom Aufbau her genauso aus wie der Create Key. Allerdings - da dieser in der Registry verbleibt - muß beim erneuten Installieren ein evtl. vorhandener Delete Key gelöscht werden.
Und natürlich muß beim Installieren wie auch beim Deinstallieren die Count Property erzeugt bzw. hochgezählt werden.

Im anfangs referenzierten Blog findet sich der Code für diese Aktionen. Das klingt kompliziert, aber man muß sich vor Augen halten, daß hier per User und per Machine Aktionen koodiniert werden müssen und der Sicherheitsmechanismus von VSTO der von ClickOnce ist - einer Technologie, die per User funktioniert.

Natürlich kann man das auch auf Basis der Inclusion List tun, Misha Shneerson erklärt das in Teil 3. Das sollte aber nur bei nichtverwalteten Netzwerken getan werden, da die zu erwartende Sicherheit geringer ist.

Bitte beachten: Es handelt sich hierbei um einen internen Office-Mechanismus. Natürlich kann man den verwenden. Es ist aber nicht garantiert, daß das Verhalten in Office-Versionen nach Office 2007 genauso ist. Eine Verwendung desselben geschieht demnach auf eigene Gefahr.

Ribbon Controls mit best. Control IDs können nicht deaktiviert werden

jensha — Tue, 06 May 2008 17:29:10 GMT

In der Liste der Control Ids sind die Namen der eingebauten Controls zu finden. Offensichtlich haben sich einige der Controls - so wie das bei Menschen auch hin und wieder üblich ist - einen zweiten Namen zugelegt. Das führt zu Unstimmigkeiten, die dazu führen, dass einige der eingebauten Controls nicht deaktiviert werden können, wenn der erste Name (auch im Anpassen Dialog der Quick Access Toolbar angezeigt) verwendet wird. Für ein simples Anzeigen der Controls und Verwenden der eingebauten Funktionalität kann auch weiterhin dieser erste Name verwendet werden.

In der nachfolgenden Tabelle finden Sie unter Control ID for Disabling den korrekten Namen des Controls zum Deaktivieren.

Somit kann mit folgenden Snippet verhindert werden, dass z.B. die Gridlines ein- bzw. ausgeschaltet werden können:

oder

VSTO 3.0 Security

jensha — Tue, 22 Apr 2008 11:24:04 GMT

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:

Name	Typ	Wert
Internet	REG_SZ	AuthenticodeRequired
LocalIntranet	REG_SZ	Enabled
MyComputer	REG_SZ	Enabled
TrustedSites	REG_SZ	Enabled
UntrustedSites	REG_SZ	Disabled

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.

Erweiterungsbibliothek für Excel-Tabellenfunktionen in Managed Code schreiben

jensha — Wed, 09 Apr 2008 15:48:00 GMT

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.

VSTO Support für Office Standard Edition

jensha — Tue, 08 Apr 2008 12:04:54 GMT

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.

Neue WebCasts zu VSTO 3.0 (Office Integration mit Visual Studio 2008) verfügbar

jensha — Mon, 07 Apr 2008 15:39:00 GMT

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.