Laden...

Installation Outlook AddIn / Outlook add-in Formularbereich in Registry

Erstellt von Miro610 vor 6 Jahren Letzter Beitrag vor 6 Jahren 5.408 Views
M
Miro610 Themenstarter:in
8 Beiträge seit 2013
vor 6 Jahren
Installation Outlook AddIn / Outlook add-in Formularbereich in Registry

Hallo community,
ich habe Probleme mit der Installation von Outlook Add-In. Ich soll ein kleines AddIn schreiben.
Mein erstes - mit Office Programmierung habe ich bis dato nichts zu tun.
Add-in sollte auf Rechner in der Firma installiert werden (Win 10 / Outlook 2013 32 bit). Ich erstelle .msi Installer mithilfe von InstallShieldLE.
Im Projekt definiere ich ein paar Registry Keys - nichts besonderes, nur das was in der MSDN Dokumentation steht. Im Project_Setup\Configure Target System\ Registry trage ich:
HKLM Software(32)-> Microsoft\Office\Outlook\Addins\MeetingExtendAddIn\ befinden sich Werte für (Default), Description, FriendlyName, LoadBehavior(3) und Manifest (f:///[INSTALLDIR]MeetingExtendAddIn.vsto|vstolocal). Installationsfolder wird auch später richtig gelesen und Dateien in den Zielordner kopiert.
Im Add-In habe ich eine zusätliche Form. Für diesen Formularbereich erstelle ich ein Registry Key
HKLM Software(32)-> Microsoft\Office\Outlook\FormRegions\IPM.Appointment mit zwei Werten: (Default) und MeettingExtendAddin.MeetingFormRegion (Data: =MeetingExtendAddIn).

Installer erstellt registry Keys in HKLM -> WOW6432Node ...weiter so wie beschrieben(Microsoft usw.).
Die .dll's und dll.manifest und MeetingExtendAddIn.vsto sind kopiert.
Leider nach dem Start Outlook deaktiviert Addin, addiert neu Registry Eintrag in HKCU unter Microsoft\Office\Outlook\AddIn: Key MeetingExtendAddIn - Value Loadbahavior(2) und schmeißt Fehler - "Ein Formularbereich kann nicht geöffnet werden. Das Formularbereichmanifest kann nicht gelesen werden. Überprüfen Sie, ob die datei vorhanden ist, und versuchen Sie es nochmal". Man kann sagen: Fehler ist eindeutig. Ok. Aber ich weiis es wirklich nicht was fehlt 😦 Die Form braucht auch ein manifest?
Form habe ich einfach in Visual Studio erstellt (Project add\New Windows Form\Outlook Form Region). Habe ich falschen Namen oder Wert für FormRegions Eintrag in Registry ausgewählt? Sollte ich noch etwas extra codieren oder einstellen?
Vielleicht hat es auch mit Form region nichts zu tun.
Ich habe wirklich viel gesucht und gelesen. Ich habe versucht den Installer für one User/all User einstellen, Registry Keys für 32 und 64 bit setzen, auch nur für 64 (was eigentlich falsch wäre). Nichts. Mit Code Signing und ohne....
Hilfe!!

PS. Wenn ich starte von Visual Studio läuft naturlich. Add In zeigt sich und funktioniert.

Grüß
Miro S.

"lesen, lernen, suchen.... und immer noch 'nix wissen' 😄"

16.806 Beiträge seit 2008
vor 6 Jahren

Ich weiß nicht, wo jetzt das Problem liegt, aber wollte Dir einen Hinweis mitgeben:

Outlook Add-Ins werden nicht mehr installiert, sondern werden über Office 365 verwaltet.

Was Du meinst sind vermutlich VSTO-Add Ins, richtig?

Jedenfalls sind COM- oder VSTO-Add Ins bereits veraltet und fliegen sicherlich auch aus der nächsten Version(en) von Outlook raus.
Aktuell sind die Outlook-Ad Ins, die auf HTML/JavaScript basieren und quasi nicht mehr im Client installiert werden müssen.
Das funktioniert seit Office 2013.

M
Miro610 Themenstarter:in
8 Beiträge seit 2013
vor 6 Jahren

Moin Abt,

ja, das ist VSTO\COm. Das die veraltet sind, wüsste ich nicht:( Ich dachte, dass weil ich grundsätzlich in WPF programmiert habe, dass mit C# wird es in meinem Fall schneler:| Na ja...
nun, was ich noch gefunden habe - wenn man von VS startet, Studio addiert noch Registry Einträge in HKCU\Software\Microsoft\VSTO. Keys Inclusion und Solution Metadata.
Ich habe dort gar nicht geschaut, weil na ja.. ich dachte da es normal ist. das es nur Projekte betrifft, die ich selber im Visual Studio gestartet/entwickelt/was auch immer habe.
Nun sehe ich, dass dort auch zwei Einträge (einen pro Key) sind für von der Firma gekauftes AddIn. Diesen habe ich bestimmt nicht gemacht;) Code nicht mal gesehen.
Sollte man sowas auch erzeugen mit dem Installer? Im MSDN habe ich nichts ähnliches gefunden.
Aber gekauftes AddIn hat diesen Eintrag. Ist das irgendein "Trick 17"? 😃
Vorschläge? Erklärung?

Grüß
Miro S.

"lesen, lernen, suchen.... und immer noch 'nix wissen' 😄"

121 Beiträge seit 2016
vor 6 Jahren

Moin Abt,

ja, das ist VSTO\COM. Das die veraltet sind, wüsste ich nicht.

Jedenfalls sind COM- oder VSTO-Add Ins bereits veraltet.

Jetzt weisst du's 😉

1.029 Beiträge seit 2010
vor 6 Jahren

OT:
Ohne COM-Addins wird es allerdings sicher einige geben die da keine Lust drauf haben... Angefangen bei den Addins für CTI-Applikationen über etliche Komfortfunktionen wie Schnelldruck von Anhängen... Hoffe jedenfalls, dass die Möglichkeit bestehen bleibt.

16.806 Beiträge seit 2008
vor 6 Jahren

Wenn es Leute gibt, die keine Lust drauf haben, dann können sie ja in Zukunft Lotus Notes verwenden :>
Wo die Technik hin geht, das ist eindeutig. Damit muss man eben sich und seine Anwendungen ebenfalls weiter entwickeln, wozu eben auch solche Erweiterungen gehören.
Nur weil es nun eine neue Technologie ist heisst es nicht, dass es dann nicht mehr geht.
Es muss evtl. nur anders umgesetzt werden.

M
Miro610 Themenstarter:in
8 Beiträge seit 2013
vor 6 Jahren

Na ja🙂 jetzt weiss ich schon🙂 Trotzdem ich möchte das Problem mit der Installation lösen.
Das Abenteuer geht weiter🙂 Nach bereinigen von Registry und erneuten install das Add In startet... Fast richtig 8o weil schreit immer noch: "Ein Formularbereich kann nicht geöffnet werden....". Allerdings es startet und öffnet sich und funktioniert. Ich frage mich zwar ständig: WTF?? 😁 aber suche weiter.
Irgendeine Leiche ist nach dem debuggen und immer wieder builden (oder installieren) geblieben.

Grüß
Miro S.

"lesen, lernen, suchen.... und immer noch 'nix wissen' 😄"

M
Miro610 Themenstarter:in
8 Beiträge seit 2013
vor 6 Jahren

Also, bevor ich mit HTML/JavaScript Add-ins starte 🙂

ich habe zwischen durch geforscht, vielleicht wird das für jemanden nützlich(obwohl VSTO veraltet ist).
Laut Doku:
"When a VSTO Add-in is installed, it can be registered in two ways:
For the current user only (that is, it is available only to the user that is logged onto the computer when the VSTO Add-in is installed). In this case, the registry entries are created under the HKEY_CURRENT_USER.
For all users (that is, any user that logs onto the computer can use the VSTO Add-in). In this case, the registry entries are created under HKEY_LOCAL_MACHINE.
All VSTO Add-ins that you create by using Visual Studio can be registered for the current user. However, VSTO Add-ins can be registered for all users only in certain scenarios. These scenarios depend on the version of Microsoft Office on the computer and how the VSTO Add-in was deployed. "
Für Fall per machine:
Die im InstallShield definierte Registry Einträge im HKLM Software(32-Bit) werden in 64-Bit System theoretisch korrekt im ..\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Office\Outlook angelegt.
Nun dann Outlook zwar starte und das AddIn funktioniert, aber im (Outlook)Debug Modus die Applikation schmeißt vorher genannten Fehler.
Es hat mich gewundert, also habe ich manuell aus WOW6432Node Eintrag für FormRegions\Nachrichtenklasse gelöscht und im HKCU angelegt. O Wunder! keine Fehler ?(
Na ja, vielleicht hat Outlook (2013/2016) kleine Probleme mit dem veralteten VSTO\COM Add-in.

Nun wollte ich per User Installation checken. Registry nach der Deinstallation geprüft, eventuelle Reste gelöscht.
Tja, falls ich die Keys direkt in HKCU erzeuge - Outlook lädt das Add-in, lässt es aber nicht aktivieren. Als hätte teilweise Info bekommen, neu Add-in mit keinen Einstellungen. 🤔
Was auch noch toll ist, falls der User im Outlook das Add-in entfernt (braucht keine Rechte, war für ihm installiert) - entfernt das Outlook HKCU Key für ausgewähltes Add-in, lässt aber "FormRegions\NachrichtenKlasse"-Key bestehen. Was zu Folgefehler
führt. Beim jeden Start Outlook meckert fehlenden Manifest für den Formularbereich... Addin ist aber gar nicht geladen 😁
Wenn man jetzt noch Add-in mit dem Installer noch mal installiert und erzeugt Keys in HKLM - kriegt man den Fehler ("Ein Formularbereich blabla...") und das beste ist, dass das Add-in startet mit zwei gleicher Formularbereichen.😁
Was man noch auf Entwicklungsrechner noch beachten muss, ist das Visual Studio beim jeden Buid von VSTO Project- auch Release - erzeugt direkt keys für addin in HKCU, mit Projektpfaden.
Wenn man das vergisst und das Add-in direkt mit dem setup/msi installiert, wundert man sich erst über verschiedene Verhaltensweise auf Entwicklungs- und Klient-Rechner.
Das alles habe ich vorher nicht gemerkt, weil ich nicht bei jeder Aktion build, install, uninstall usw. die Registry auf beiden Rechner genau untersucht habe. Also nicht jedes Mal alles.
Was ich nicht rausgefunden habe, ist why wenn ich mit dem Installer Key für Add-in in HKLM\WOW6432Node anlege und für FormFegions\Nachrichtenklasse
in HKCU Add-in startet aber Fehler besteht. Beim manuellen Eingriff funktioniert es ohne Fehler. Ich habe in Registry dafür keinen Grund gefunden bzw. diesen übersehen.

So, vielleicht wird das oben jemanden ein bisschen Zeit sparen. Beim ähnlichen Aktionen direkt alles Mögliche in Registry überwachen :evil:

Grüß
Miro S.

"lesen, lernen, suchen.... und immer noch 'nix wissen' 😄"