Open XML, VSTO, Deployment, .NET und anderes : Setup & Deployment

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.

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.

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.

File Extension per ClickOnce mit Anwendung assoziieren

jensha — Thu, 10 Apr 2008 19:26:00 GMT

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:

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.

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.

Verteilung von VSTO 2005 SE - Lösungen [Teil 5]

jensha — Tue, 26 Feb 2008 18:24:00 GMT

Build und PostBuild und ein paar Bugs

Damit ist es geschafft. Fast zumindest. Das Projekt kann kompiliert werden. Es wird aber auf den meisten Systemen nicht installiert werden können. Beim Installieren unter Windows Vista erscheint eine Fehlermeldung kurz vor Ende der Installation: Error 2867. Oder auch Error 2869 und zwar ohne weitere Erklärung. Die Ursache ist der Visual Studio Installer, der einerseits einen Eintrag in der Error Table vergessen hat und desweiteren eine Verhaltensweise des Windows Installers, der die Custom Actions im Kontext des angemeldeten Benutzers ausführt. Und zwar unabhängig von einem evtl. erscheinenden Elevation Prompt des User Account Controls (UAC). Um Code Access Security setzten zu dürfen, benötigt man allerdings entsprechende Rechte, die der Standard User nicht hat. Somit schlägt die Ausführung der Custom Action fehl.

Im verbose Log des MSI (msiexec /i MyInstaller.msi /L*v Logfile.log) steht dann etwas von „ActionType=1025“. Das setzt sich zusammen aus: msidbCustomActionTypeInScript (1024) + (bzw. OR) msidbCustomActionTypeDll + msidbCustomActionTypeBinaryData (1) und sollte dem Entwickler sagen, dass etwas fehlt.

Um das Problem zu lösen, muss die Typinformation der Custom Action um msidbCustomActionTypeNoImpersonate (2048) erweitert werden. Daraus ergibt sich Typ 3073. Damit wird der Custom Action (InstallUtil) Process nicht impersoniert und läuft mit den erforderlichen Rechten. Der Typ kann auch für die UnInstall Custom Action verwendet werden. Für die RollBack Custom Action kommt noch msidbCustomActionTypeRollback (256) hinzu, was dann zum Wert 3329 führt.

Die Änderungen lassen sich leider nicht direkt im Visual Studio Installer durchführen, sondern man muss sich ein Tool aus dem MSI SDK (Bestandteil des Windows Plattform SDK) namens ORCA (nicht zu verwechseln mit ORCAS, dem Codenamen der nächsten Version von Visual Studio) holen. ORCA ist ein Editor für die in einem MSI Paket enthaltene relationale Datenbank. Damit kann das fertige MSI Paket geladen und modifiziert werden (in diesem Fall die CustomActions Table).

Die zweite Änderung betrifft die Error Table. Dort wurde nämlich vergessen, auftretende Fehler auch ans User Interface weiter zu geben. Ein Eintrag mit Error = „1001“ und Message = „Error [1]: [2]“ behebt die Misere.

In Visual Studio 2008 sind diese Probleme übrigens behoben.

Software Life Cycle

Dank Visual Studio Tools for Office, Managed Code und Entwicklung in Visual Studio selbst ist auch die reibungslose Integration von Office-Lösungen in den Software Life Cycle gegeben. Visual Studio Team System und Team Foundation Server benötigen keiner besonderen Vorbereitung. So ist Ihr Source Code in besten Händen und Testszenarien können ebenso aufgebaut werden wie Implementierungsregeln. It’s just managed Code.

Fazit

Das Deployment von Lösungen auf Basis von VSTO ist einfacher geworden, wenn auch nicht ganz ohne Probleme. Weiß man allerdings um die wenigen Klippen, kann man sich viele Stunden des Suchens ersparen. Sicherlich ist die Versionsabhängigkeit von VSTO in Bezug auf Office ein Problem (VSTO 2.0 gegen Office 2003, VSTO 2005 SE gegen Office 2007, dokumentzentrische Projekte müssen aber generell mit VSTO 2.0 gegen Office 2003 geschrieben werden, laufen aber unter der Runtime von SE und gegen Office 2007…). VSTO 3.0 wird Office 2003 und 2007 unterstützen und vollständig im neuen Visual Studio 2008 (Professional Edition) enthalten sein. Damit ist dann auch das letzte Missverständnis um den Inhalt der Pakete (VSTO 2.0 ist eigentlich ein Visual Studio Pro mit VSTO aber ohne Mobility-Entwicklung und VSTO 2005 SE ist ein kostenloses Add-On für Visual Studio 2005) ausgeräumt sein.

Prerequisites für VSTO-Lösungen

.NET Framework 2.0

http://www.microsoft.com/downloads/details.aspx?FamilyID=0856eacb-4362-4b0d-8edd-aab15c5e04f5

VSTO 2005 SE Runtime (unterstützt ebenfalls VSTO 2.0)
http://www.microsoft.com/downloads/details.aspx?FamilyId=F5539A90-DC41-4792-8EF8-F4DE62FF1E81

Office Primary Interop Assemblies (Sind Bestandteil von Office, aber nicht überall installiert, da eine Installation das .NET Framework voraussetzt)

http://www.microsoft.com/downloads/details.aspx?familyid=59DAEBAA-BED4-4282-A28C-B864D8BFA513

Links & Literatur

[1] Deploying Visual Studio 2005 Tools for Office Second Edition Solutions Using Windows Installer
http://msdn2.microsoft.com/en-us/library/bb332051.aspx
http://msdn2.microsoft.com/de-de/library/bb332051.aspx

http://msdn2.microsoft.com/en-us/library/bb332052.aspx
http://msdn2.microsoft.com/de-de/library/bb332052.aspx

[2] Deploying Office Solutions
http://msdn2.microsoft.com/en-us/library/hesc2788(VS.80).aspx

[3] CasPol.exe
http://msdn.microsoft.com/library/deu/default.asp?url=/library/DEU/cptools/html/cpgrfCodeAccessSecurityPolicyUtilityCaspolexe.asp

[4] Deployment Models
http://msdn2.microsoft.com/en-us/library/7b37fkst(VS.80).aspx

[5] Application Manifest Editor Sample
http://msdn2.microsoft.com/en-us/library/ms268756(VS.80).aspx

[6] Smart Client Offline Application Block
http://www.microsoft.com/downloads/details.aspx?FamilyId=BD864EB5-56B3-43A5-A964-6F23566DF0AB

[7] Bootstrapper Manifest Generator
http://www.codeplex.com/bmg

[8] Was darf mein Code? - Das Sicherheitsmodell der Common Language Runtime
http://www.microsoft.com/germany/msdn/library/security/WasDarfMeinCodeDasSicherheitsmodellDerCommonLanguageRuntime.mspx

[9] Sicherheit in Office-Projektmappen
http://msdn2.microsoft.com/de-de/library/k64zb6we(VS.80).aspx

+++ Ende der Serie +++

VSTO 3.0 Runtime zum Download verfügbar

jensha — Thu, 29 Nov 2007 12:58:21 GMT

Die Runtime für Visual Studio Tools for Office, Version 3.0 ist hier herunterladbar. Vorerst nur in der englischen Version, aber sobald die lokalisierten Versionen von Visual Studio 2008 verfügbar sind, wird es gibt auch unterschiedliche Sprachversionen geben.

Diese Runtime ist notwendig für VSTO-Lösungen, die mit Visual Studio 2008 erstellt worden sind.

VSTO 2005 SE Add-In Deployment / ALLUSERS

jensha — Tue, 27 Nov 2007 13:43:32 GMT

Eine wesentliche Limitierung von managed Office 2007 Add-Ins ist die Beschränkung auf eine per-User - Installation. Selbst wenn Sie die erforderlichen Einträge (wie von mir im .NET Magazin / Ausgabe 10.07 beschrieben) auf HKLM umlegen, ignoriert Office 2007 Ihr Add-In.

Misha Shneerson, Entwickler im VSTO-Team, legt nun offen, wie Sie Office 2007 Add-Ins dennoch so installieren können, dass sie von allen Usern einer Maschine genutzt werden können. Es ist ein wenig Magie bei der Geschichte, aber es ist völlig legal und funktioniert.

Hier geht's zu den beiden Artikeln:

Deploying your VSTO Add-In to All Users (Part I)

Deploying your VSTO Add-In to All Users (Part II)

Auf die Runtime kommt es an

jensha — Tue, 13 Nov 2007 18:45:36 GMT

Wer es noch nicht entdeckt hat: es gibt eine aktualisierte Runtime für VSTO 2005 SE, die alle bis dahin (Juli 2007) verfügbaren Fixes enthält.

Microsoft Visual Studio 2005 Tools for Office Second Edition Runtime

(build 8.0.50272.891) (x86)

Korrektur des dot.net Magazin-Artikels "Paketschieber"

jensha — Tue, 04 Sep 2007 17:28:00 GMT

In der Ausgabe 10.07 des dot.net Magazins wurde leider von den Redakteuren des Verlags ein Teil meines Artikels (Office Lösungen auf der Basis von VSTO 2007 richtig paketieren und ausliefern) "verschlimmbessert". Da heißt es auf Seite 25 in Spalte 3, der Windows Installer könne die Registry-Einträge automatisch nach HKLM umsetzen, wenn er die Installation für alle Benutzer erkennt. --- Fast. Man muß ihm das nur sagen.
Außerdem ist wohl die Einschränkung bzgl. Add-Ins für alle Benutzer und Office 2007 unter den Tisch gefallen.

Korrekt sollte es so heißen:

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“ verschieben, 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.

Desweiteren sind Launch Conditions keine Benutzerdefinierten Aktionen sondern Startbedingungen.

FireFox goes ClickOnce

jensha — Thu, 31 May 2007 11:10:00 GMT

Für alle, die es noch nicht gesehen haben: für FireFox gibt es ein AddOn, mit dem ClickOnce unterstützt wird. Unterstützte Versionen: FireFox 1.5 .. 2.0.

Zum Download

Deployment von VSTO 2005 SE Lösungen

jensha — Tue, 20 Mar 2007 17:16:00 GMT

Das Deployment der eigenen Anwendung ist mindestens genauso wichtig wie die Anwendung selbst. Zum einen, weil dies den ersten Kontakt Ihres Kunden mit Ihrer Anwendung darstellt und zum anderen, weil sie hier entscheidet, ob Ihre Anwendung überhaupt verwendet werden kann oder schon während des Setups scheitert. Überlassen Sie also die Erstellung eines prfessionellen Setups nicht einem hastig dafür eingestellten Studenten, sondern planen Sie das Setup und Deployment schon während der Arbeit an Ihrem Projekt.

VSTO bildet da keine Ausnahme und deshalb hast sich ein Teil der VSTO-Produktgruppe um Darryn Lavery die Zeit genommen, das ganze Prozedere in einem Whitepaper nieder zu schreiben. Während Teil 1 erklärt, welche Prerequisites erforderlich sind und wie diese in Form von Bootstrapper Packages auf die Zielmaschine kommen, finden Sie in Teil 2 zwei WalkTroughs, die zeigen, wie das Ganze Schritt für Schritt durchgeführt wird. So ist ein wichtiger Aspekt ebenfalls vertreten: Wie setzet man die Code Access Security Policy automatisch während des Setups für die VSTO Solution. Hier wird mit einer Custom Action gearbeitet, die z.T. Daten vom MSI-Paket übernimmt (z.B. die ALLUSERS Property) und dann programmatisch CAS einstellt.

Fazit: Wer VSTO-Lösungen baut, braucht dieses Whitepaper

Hier eine kurze Inhaltsübersicht:

Deployment Overview for Visual Studio Tools for Office Solutions
Deployment Methods for Visual Studio Tools for Office
Using Windows Installer to Deploy a Solution
Known Issues Deploying Visual Studio 2005 Tools for Office Solutions
Product Codes and Component IDs

Walkthrough: Enhancing the Outlook Add-in Setup Project
Walkthrough: Creating Windows Installer Packages to Deploy Visual Studio 2005 Tools for Office SE Solutions

Visual Studio Installer: Custom Actions in eigener Installer Class

jensha — Fri, 12 Jan 2007 11:45:00 GMT

Bin ich doch wieder mal mit meiner eigenen Vergangenheit kollidiert. Wo? Beim Schreiben einer Installationsroutine für ein Outlook Add-In. Welche? MSI.

Wie gesagt, ich hatte vor, ein MSI Package zu erzeugen, welches ein Outlook Add-In [erzeugt mit VSTO 2005 SE] installiert und gleichzeitig auch noch die Trust Relationship [Code Access Security] setzt. Also eine Code Group anlegt und - basierend auf dem Strong Name, mit dem die DLL signiert wurde - FullTrust setzt. Gesagt - getan. Installer Class als neues Item der DLL hinzufügen und Install oder Commit, UnInstall und Rollback überschreiben:

public override void Install(System.Collections.IDictionary stateSaver)
{
base.Install(stateSaver);
CreatePolicy("User", "ContactManager", "CodeGroup for VSTO AddIn for Outlook");
}

Dann noch die Custom Actions im Setup mit der DLL verbinden:

... und es sollte funktionieren. So hatte ich mir das gedacht.

Beim Installieren unter Windows Vista bekam ich dann prompt die Quittung: Error 2867. Im Log (msiexec /i <package name> /l*v <Logfile>) stand dann folgendes:

MSI (s) (9C:20) [17:19:41:665]: Executing op: CustomActionSchedule(Action=_6B611CFE_8C2D_44E5_9087_8802C25060B3.install, ActionType=1025, Source=BinaryData, Target=ManagedInstall, CustomActionData=/installtype=notransaction /action=install /LogFile= /InstallPath="C:\Program Files\..." "C:\Program Files\..." "C:\Users\<username>\AppData\Local\Temp\CFG2322.tmp")

MSI (s) (9C:94) [17:19:41:665]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI277A.tmp, Entrypoint: ManagedInstall

MSI (s) (9C!70) [17:19:41:743]: Note: 1: 2262 2: Error 3: -2147287038
MSI (s) (9C!70) [17:19:41:743]: Note: 1: 2262 2: Error 3: -2147287038
MSI (s) (9C!70) [17:19:41:743]:
MSI (s) (9C:94) [17:19:41:743]: Leaked MSIHANDLE (12) of type 790531 for thread 5744
MSI (s) (9C:94) [17:19:41:743]: Note: 1: 2769 2: _6B611CFE_8C2D_44E5_9087_8802C25060B3.install 3: 1
MSI (s) (9C:94) [17:19:41:743]: Note: 1: 2262 2: Error 3: -2147287038

Error 1001.
DEBUG: Error 2769: Custom Action _6B611CFE_8C2D_44E5_9087_8802C25060B3.install did not close 1 MSIHANDLEs.

The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2769. The arguments are: _6B611CFE_8C2D_44E5_9087_8802C25060B3.install, 1,

Schwach erinnerte ich mich der verschiedenen Typen für Custom Actions und suchte heraus, was 'ActionType=1025' bedeutet.

msidbCustomActionTypeInScript (1024)
Queues for execution at scheduled point within script. This flag designates that this is a deferred execution custom action.

+ (bzw. OR)

msidbCustomActionTypeDll + msidbCustomActionTypeBinaryData (1)

Der Process wird von InstallUtil.exe ausgeführt und läuft by default im Security Context des angemeldeten Benutzers. Und hier liegt der Hase im Pfeffer. Beim Start des MSI Pakets kommt der Prompt für elevated Execution. Wenn ich das erlaube, wird das Setup als Admin ausgeführt, nur eben nicht die Custom Action, die weiterhin im User Context läuft. Das ist fatal, wenn sie Admin Rechte benötigt.

Um das Problem zu lösen, muß die Typinformation um msidbCustomActionTypeNoImpersonate (2048) erweitert werden. Daraus ergibt sich Typ 3073. Damit wird der CA (InstallUtil) Process nicht impersoniert und läuft als Admin (bzw. im LocalSystem Account). Der Typ kann auch für die UnInstall Custom Action verwendet werden. Für die RollBack Custom Action kommt noch msidbCustomActionTypeRollback (256) hinzu, was dann zum Wert 3329 führt.

Die Änderungen lassen sich leider nicht direkt im Visual Studio Installer durchführen, sondern man muß sich ein Tool aus dem MSI SDK (Bestandteil des Windows Plattform SDK) namens ORCA holen. Damit kann das fertige MSI Paket geladen und modifiziert werden (in unserem Fall die CustomActions Table).

Übrigens, wie Code Groups und Trust Relationships programmatisch angelegt werden, finden Sie hier bzw. hier. Für den Fall, daß eine StrongNameMembershipCondition verwendet werden soll, kann der Public Key so ermittelt werden:

Assembly thisAsm = this.GetType().Assembly;
AssemblyName asmName = thisAsm.GetName();
byte[] asmKey = asmName.GetPublicKey();
StrongNamePublicKeyBlob snPKBlob = new StrongNamePublicKeyBlob(asmKey);
StrongNameMembershipCondition snMemCond = new StrongNameMembershipCondition(snPKBlob, null, null);

Rechtevergabe für Ordner, Dateien und Registry-Einträge bei der Installation

jensha — Tue, 09 Jan 2007 18:42:00 GMT

Oftmals ist es notwendig, die Zugriffsrechte für Ordner, Dateien bzw. (auch das soll noch verwendet werden) Registry-Einträge einzuschränken. Vielfach liest man dann Anleitungen, wie dem Windows Installer (MSI) Scripts als Custom Actions untergeschoben werden, um selbiges zu bewerkstelligen. Dabei geht es einfacher und sicherer.

Mit Hilfe der LockPermissions Table kann das nämlich mit Bordmitteln erledigt werden. Nach einer Anfrage habe ich meine schon etwas angestaubte MSI-Vergangenheit hervorgekramt und will auch nicht versäumen, das Ganze hier für die Nachwelt zu erhalten.

Hier ein Snapshot der LockPermissions Table, in der jeweils ein Registry Key, File bzw. Folder (müssen in den entsprechenden Tabellen des MSI definiert sein) mit verschiedenen Rechten für User bzw. Administratoren versehen werden.

In der Spalte 'User' wird der entsprechende Username oder besser Gruppenname (engl. Bezeichnung) eingetragen, für die die Einschränkung gelten soll.

Das Aha-Erlebnis kommt allerdings in der Spalte 'Permissions'. Was soll ich dort eintragen? Man muß sich schon etwas (sehr) mit Programmierung beschäftigen, um darauf zu kommen, daß die Konstanten in C++ Header-Dateien zu finden sind. Das sind nämlich dieselben, die ein Entwickler, welcher die Win32 APIs verwendet, bemühen muß. Man findet sie im Windows Plattform SDK.

Hier noch ein Beispiel für die Berechnung. Ja, es handelt sich meist um eine Berechnung von Hexadezimalwerten, da sich eine Konstante oftmals aus der bitweisen (OR-) Verknüpfung von anderen Konstanten zusammensetzt.

Natürlich muß das Setup dann mit 'elevated Privileges' ausgeführt werden (z.B. per Group Policy).

ClickOnce & Proxy Authentication

jensha — Wed, 12 Jul 2006 10:17:00 GMT

Wegen verstärkter Nachfrage hier die Info bzgl. ClickOnce Deployment und Proxy Authentication. Es kommt zu einem Fehler beim Download der Dateien. Im Protokoll kann man nachlesen:

Der Remoteserver hat einen Fehler zurückgegeben: (407) Proxyauthentifizierung erforderlich.

Es gibt dafür einen Hotfix beim Microsoft Support (bekommt man leider nur über anrufen). Allerdings funktioniert das nur mit den "default credentials", also ohne Paßwort-Eingabe.

Man kann als Ausweg versuchen, evtl. vorher auf die Webseite zu navigieren, Username und Paßwort einzugeben und die Frage "Remember my password" zu bestätigen, was aber nicht sonderlich zufriedenstellend ist.

Configuration Issues in ClickOnce Deployments