Jens HäupelPlatform Strategy ManagerMicrosoft Deutschland GmbH These postings are provided "AS IS" with no warranties, and confer no rights. Use of included code samples are subject to the terms specified at Microsoft - Information on Terms of Use
Das Deployment für VSTO Lösungen funktioniert immer noch mit ClickOnce (MSI geht auch, aber ohne besondere Visual Studio-Unterstützung). Das Security Modell ist ebenfalls gleich geblieben (ClickOnce Security mit signierten Manifesten und Trust Chain). Zwei Dinge sind aber neu: Multi Target Deployment und Post Deployment Actions. Mit letzterem will ich mich in diesem Artikel auseinander setzen.
Wenn nach der eigentlichen Verteilung von AddIns oder anderen VSTO-Lösungen noch weitere Aktionen ausgeführt werden sollen, so war das bisher mit ClickOnce nicht möglich. MSI kennt das Prinzip der Custom Actions. So etwas ähnliches gibt es jetzt bei Click Once – eben jene Post Deployment Actions.
Dazu wird eine neue Klasse dem Projekt hinzugefügt, nennen wir sie einmal PDAClass. Diese Klasse benötigt folgenden Namespace:
using Microsoft.VisualStudio.Tools.Applications.Deployment;
Von diesem kommt die Definition der Basisklasse, von der unsere Klasse erbt:
class PDAClass : IAddInPostDeploymentAction
Jetzt muss nur noch die Execute-Methode implementiert werden:
public void Execute(AddInPostDeploymentActionArgs args) { … }
Innerhalb der Execute-Methode können Aktionen durchgeführt werden, die im User Context erlaubt sind (ClickOnce-Regel!). Ausgeführt wird der Code nach dem eigentlichen Kopieren bei der ClickOnce-Installation.
Das ist allerdings nur die eine Seite der Medaille. Da die Aktivierung des Codes bei der Installation erfolgt (automatisch durch den ClickOnce Mechanismus), müssen wir selbigem auch mitteilen, das da etwas zu tun ist. Das geschieht, indem ein Eintrag ins Application Manifest (.manifest) erfolgt:
Nach dem Statement:
<vstav3:update enabled="true" />
fügen wir folgendes ein:
<vstav3:postActions> <vstav3:postAction> <vstav3:entryPoint class="MyAddIn.PDAClass"> <assemblyIdentity name="MyAddIn" version="1.0.0.0" language="neutral" processorArchitecture="msil" /> </vstav3:entryPoint> <vstav3:postActionData></vstav3:postActionData> </vstav3:postAction> </vstav3:postActions>
Hierbei muss darauf geachtet werden, dass vstav3:entryPoint class=”<Namespace.Class>” erhält. Außerdem wird assemblyIdentity name="Namespace" und version="1.0.0.0" auf die aktuelle Version der Assembly gesetzt.
Nachdem das Manifest geändert worden ist, stimmt natürlich der beim Signieren erzeugte Hash nicht mehr und beide Manifeste müssen neu signiert werden. Zuerst das Application Manifest und danach das Deployment Manifest (.vsto).
Dazu wird am einfachsten eine Batch-Datei mit folgendem Inhalt erzeugt:
Mage -sign "<Pfad zum Application Manifest>\MyAddIn.dll.manifest" -certfile "<Pfad zum Zertifikatsfile>\MyCert.pfx" -pwd <Passwort>
Mage -update "<Pfad zum Deployment Manifest>\MyAddIn.vsto" -appmanifest "<Pfad zum Application Manifest>\MyAddIn.dll.manifest" -certfile "<Pfad zum Zertifikatsfile>\MyCert.pfx" -pwd <Passwort>
Wichtig: Das verwendete Mage (Manifest Generation Tool) muss das aus dem .NET Framework 4.0 sein.
Visual Studio 2010 unterstützt Office 2010 und 2007, aber nicht Office 2003. Dafür müsste VS2008 parallel installiert werden. Das ist kein Problem. Allerdings sollte man keine 2 Office Versionen parallel installieren. Dann also doch lieber virtualisiert oder auf einem anderen Rechner.
Alle 2007er Projekt-Szenarios gibt es auch für Office 2010.
Der Ribbon Designer wurde zwar erweitert, allerdings lassen sich komplexere Aufgaben nur mit Hilfe von RibbonX, der XML Markup-Sprache, entwickeln.
Was ist also neu?
Programmatische Aktivierung der Tabs:
Aus dem Kontext heraus können Tabs gezielt angesprungen werden, z.B. beim Laden des AddIns. Sowohl eingebaute Tabs (this.ribbon.ActivateTabMso("TabHome");) als auch eigene (this.ribbon.ActivateTab("Contoso");) können aktiviert werden.
Automatische Skalierung der Icons:
Per AutoScale-Property wird die automatische Skalierung von Gruppen eingeschalten:
<group id="grpContoso" label="Contoso" autoScale="true"> …
</group>
Alles voll sichtbar:
Die letzte Gruppe wird herunterskaliert:
Die zweite Gruppe wird herunterskaliert:
Die letzte und die erste Gruppe wird herunterskaliert:
Die dritte Gruppe hatte AutoScale=False.
Kontextmenüs:
Per RibbonX kann man sich sehr einfach in bestehende Kontextmenüs einhängen.
<contextMenus> <contextMenu idMso="ContextMenuCell"> <button id="ctxButton" label="Contextmenu Button" imageMso="Drawing1GalleryBrightness" onAction="OnCtxButtonAction"/> </contextMenu> </contextMenus>
Backstage:
Das ist ein Bereich, welcher in Office 2007 z.T. vom Office Menü ausgefüllt und in 2010 erweitert wurde. Hier ist der richtige Platz für Metadaten (Dateiinfo, Workflow-Status, etc.) und Operationen über das komplette Dokument (Speichern, Drucken, etc.).
Es können Tabs und FastCommands angelegt werden. Tabs bilden ähnlich wie Ribbon Tabs eine kontextuelle Gruppierung und FastCommands sind schnelle Einsprungpunkte auf Eigenschaften oder Befehle.
Wie im Bild zu sehen ist, können zwei Spalten innerhalb eines Tabs mit Funktionalität versehen werden. Jede Spalte kann Gruppen mit Primären Items, Top Items und Bottom Items enthalten und in der Ausprägung “Information”, “Warning” und “Error” einher kommen.
Außerdem kann die prozentuale Breite der ersten Spalte definiert werden. Ohne diese Angabe wird 50/50 aufgeteilt.
Man kann sich auch in bestehende Tabs integrieren und eigene Inhalte aufbauen. Das wird dann am Ende bestehender Inhalte angefügt.
<tab idMso="TabPrint"> <firstColumn> <group id="MyGroup"> <primaryItem> <button id="btnMyPrim" …
Hier ein Beispiel für den Backstage Tab aus dem Bild oben:
<tab id="bsTab" label="Contoso" columnWidthPercent="65"> <firstColumn> <group id="bsGroupOne" label="…" style="normal"> <primaryItem> <button id="bsGroupOneButton" label="…" imageMso="HappyFace" onAction="OnBackstageGroupButtonAction"/> </primaryItem> <topItems> <checkBox id="chkOption1" label="Option 1"/> <checkBox id="chkOption2" label="Option 2"/> </topItems> <bottomItems> <labelControl id="lbl1" label="Hier beginnen die Bottom Items: "/> <button id="bsBottomButton" label="Bottom Items Button"/> </bottomItems> </group> <group id="bsGroupSC1" label="Die zweite Spalte erscheint hier" style="normal"> <primaryItem> </primaryItem> <topItems> <imageControl id="imgGroupSC" getImage="OnGetImage"/> <layoutContainer id="lcMain" layoutChildren="horizontal"> <button id="btnGroupFourBuy" label="Kaufen" imageMso="DistributionListAddNewMember" onAction="OnBuyAction"/> <hyperlink id="hl1" label="Schau auf Jens' Blogseite" target="http://blogs.msdn.com/jensha"/> </layoutContainer> </topItems> </group> <group id="bsGroupSC2" label="..." style="warning"> <topItems> <labelControl id="lbl2" label="…"/> </topItems> </group> </secondColumn> </tab>
Wie immer sind die ControlIDs und CallBackHandler-Signaturen in der MSDN dokumentiert.
Quellen:
Ribbon Overview in Office 2010
UI Extensibility in Office 2010
bekanntlich verhindert ja Office 2007, dass VSTO-AddIns (managed Code) von HKLM geladen werden. LoadBehavior wird dabei immer wieder auf 2 zurückgestellt.
Das Office Team hat jetzt (nachdem Office 2010 das sowieso wieder erlaubt) auch einen Patch für Office 2007 herausgebracht, der diese Möglichkeit wieder erlaubt:
A 2007 Office system application does not load an add-in that is developed by using VSTO
http://support.microsoft.com/kb/976811
Beachten sollte man allerdings, dass der (Standard-) Benutzer diese AddIns nicht deaktivieren kann!
Weitere Infos:
In Microsoft Office 2003 and earlier, COM add-ins could be registered in HKEY_LOCAL_MACHINE and this had the following effects:
• They were available for all Windows user profiles
• They did not appear in the COM Add-ins window so therefore the user could not remove the add-in.
In the original version of Office 2007, this behavior was changed so that add-ins developed using Visual Studio Tools for Office (VSTO) and registered in HKEY_LOCAL_MACHINE would not load. In addition, Office 2007 was originally designed so that other add-ins registered in HKEY_LOCAL_MACHINE would appear in the user interface and could be disabled by using the COM Add-ins window.
After installing the hotfix and enabling it using the EnableLocalMachineVSTO registry key, add-ins developed using VSTO will load. However, by default they will still be displayed in the user interface. These types of add-ins can be optionally hidden in the COM Add-ins window by deploying the DontDisplayHKLMAddins additional registry key. For more information, see:
929590 Known issues when you develop custom solutions for Office Outlook 2007
http://support.microsoft.com/default.aspx?scid=kb;EN-US;929590
The end result is that by deploying both the EnableLocalMachineVSTO and DontDisplayHKLMAddins registry keys, Office 2007 will now revert back to Office 2003 (and earlier) behavior for VSTO-based add-ins. The only difference is that the add-ins will be listed in the new Office 2007 Trust Center. However, users will not be able to remove them because they will not appear in the COM Add-ins window.
Just nach der Basta hat es mich erwischt. Beim Badminton, nach einem zugegebenermaßen nicht gerade lehrbuchhaften Abwehrschlag von der Grundlinie, hat sich meine Achillessehne verabschiedet. Glatter Abriss. Inzwischen ist es wieder zusammen genäht worden (sieht aus, wie der zugenähte Bauch einer ausgestopften Weihnachtsgans ;-))
Irgendwo habe ich gelesen, dass eine solche Achillessehne bei einem erwachsenen Menschen bis zu einer Tonne Zugkraft aushält. Da kann man mal sehen, was Hebel so alles bewirken. Jedenfalls bin ich in den nächsten 6..7 Wochen sehr immobil.
Ab nächste Woche werde ich dann aber wieder etwas mehr zum neuen VSTO schreiben, sowohl hier für den Blog als auch für einen neuen Artikel im dotNet Magazin.
Ich werde versuchen, alle Fragen, die in den letzten 3 Wochen eingegangen sind, bald zu beantworten.
March, 2010 - Office Development is more than VBA - Site Home - MSDN Blogs