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.
