Freigeben über

VSTO NEXT

  • Artikel

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.

Comments