Office: (Office 2003) Meldungsfenster bei Mailversand über MAPI

Ein Add-In, das mit VSTO erstellt wurde, muss immer noch als COM-Add-In registriert werden?
Ich dachte, dass läuft dann über die ms.net Unterstützung für Office (oder wie auch immer das Dingens heißt, das man im Setup auswählen kann bzw. das vermutlich standardmäßig ausgewählt ist).

Folgendes fand ich zur Installation: Deployment von VSTO Addins
=> Click Once Deployment

mfg
Josef

 

Ahja, ok, die Reg-Infos zum Addin selbst können für Office-Apps - im Unterschied zu VBA-Addins - ja auch unter HKCU stehen.
Um die Schnittstellenklasse mit IDExtensibility kommt man doch aber nicht rum, oder?
Und die muss halt dann in HKCR-clsid, -interface und -typelib verewigt sein.
Aber vielleicht täuscht mich auch meine Erinnerung; habe mit VSTO schon länger keine Experimente mehr gemacht. Glaube mich zu erinnern, dass die Office-Assemblies nur Schnittstellen zu den COM-Interfaces der Apps sind.

Ciao, Sascha

 

Ich testete es gerade. Installation funktionierte ohne Admin-Rechte und es läuft auch. *wink.gif*
Mein Test-Code:
Code:

In den Projekteigenschaften auf "Publish" klicken und dann das dadurch erzeugte Setup ausführen.


Ich vermute aber, dass das für den OLConnector nicht viel bringen wird, weil man von Access aus (also über COM) zugreifen können muss.
Wenn es aber keine COM-sichtbaren Klassen gibt, wird das schwierig werden.

mfg
Josef

 

Hi,

Ich hatte es parallel auch getestet. *wink.gif*
Mit dem gleichen Ergebnis: ClickOnce braucht nur das .vsto-Manifest, um die Assembly-DLL per RSA zu "legalisieren", wozu beim Setup allerlei Registry-Einträge unter HKCU vorgenommen werden. Admin ist nicht nötig.

Dann aber wurde mir auch klar, dass man weder über Interop-Application, noch [_Application] an ein COM-Objekt kommt... *frown.gif*
Vielleicht geht's irgendwie, aber das marshaled-Zeugs übersteigt meinen Horizont. Mal abgesehen, davon, dass ich nur wenig Lust verspüre, den OLConnector komplett auf NET zu portieren, was so einfach auch nicht wäre.

Ciao, Sascha

 

Jetzt seid ihr Beiden mir zuvor gekommen mit der Testerei *wink.gif*
Wollte gerade einen Testlauf starten.

Ich hab auch irgendwo im Hinterkopf, dass es eine Selektionsmöglichkeit gab, ob das AddIn/VSTO-Teil für alle oder nur für den aktuellen User sein soll.
Abhängig der Auswahl wurde dann in HKLM bzw. HKCU geschrieben.
Kann aber auch sein, dass ich das mit dem SharedAddIn verwechsel.

@Sascha: Portierung von COM-AddIn auf .NET?
Wie sagte gestern ein Kollegen in nem Meeting: "Ach, das geht ganz einfach. Einfach in VB.NET konvertieren und dann läuft das schon..." ich konnt mir ein schmunzeln nicht verkneifen...

Noch was w/ VSTO: Ich hab irgendwie das Gefühl, dass hier im Hintergrund immer noch sehr vieler über COM kommuniziert wird... was nicht unbedingt schlecht sein muss, aber eben genau die von Dir genannten Schwierigkeiten mit der Interop aufwirft.

Noch eine Anmerkung, bei der mir evtl. jemand helfen kann:
Ich habe auf einem Rechner auf dem ich auch die VSTOs entwickle sowohl Office12 als auch Office14.
Bei der Entwicklung ändere ich die PIA von den Office14.dll's (die automatisch beim anlegen gesetzt wurden) auf die entsprechenden Office12.dll's.
Warum? Weil das AddIn sowohl unter Office12 als auch unter Office14 laufen soll/muss.
Klappt an sich auch wunderbar, solange ich keine speziellen Office14-Features nutze (was auch klar ist).
Problem ist folgendes: Wenn ich das fertige AddIn auf einem Client installiere, der nur Office12 hat, bekomme ich diverse Laufzeitfehler, dass die Office14-PIAs nicht gefunden werden können (logisch... woher auch).
In der Solution finde ich keine Möglichkeit diese offenbar intern gespeicherten Referenzen zu entfernen.
Man sieht sie nur, wenn ich die kompilierte dll durch einen Disasembler jage...

Nichts tragisches, ich umgehe das ganze einfach, indem ich auf einem Client entwickle, der nur Office12 hat (das geht durch die Abwärtskompatibilät bisher fehlerfrei).
Jemand eine Idee dazu?

 

\@Benny: ich nutze VSTO nicht, daher habe ich mich auch noch nicht damit beschäftigt, was wo gespeichert wird. Aber konntest du in der Projektdatei nichts finden? ... z. B. wenn du die Projektdateien von leeren Add-Ins von den 2 Clients vergleichst.

mfg
Josef

 

Hatte ich damals eigentlich auch geschaut aber ich prüf das nochmal... wir sind dann nur zusammen mit nem Kollegen von MS fündig geworden indem wir das ganze durch den Disassembler gejagt haben...

Wie gesagt, ist nichts tragisches, da ich einen Workaround habe.
Der allerdings bedeutet, ich muss auf meinem Client momentan auf Office14 verzichten *frown.gif*

Nachtrag:
Wenn man(n) weiß, wonach man suchen muss wird man auch fündig.
Glaube ich hab den entsprechenden Bereich in der csproj gefunden... ich teste das demnächst mal.

 

\@Benny:

Im Prinzip hat er nicht so unrecht.
Wäre das nur ein Addin, das innerhalb Outlook irgendwelche Sachen macht, dann ginge das relativ einfach.
Da die Funktionalität des OLConnectors aber von außerhalb benötigt wird und er sich in der ROT registrieren muss, müsste man die Pfade von NET verlassen und eine konsequente Übersetzung NET-Klassen > COM-Interfaces einbauen, um von etwa Access aus die NET-ApplicationClass steuern zu können. Anders kann ich mir das nicht vorstellen.

Ciao, Sascha

 

Genau das Thema ROT und Kommunikation nach aussen (bzw. von aussen nach innen) war beim betrachteten AddIn/Programm eben auch ein Thema... und da hätte ich doch meine Bedenken, dass das ganz simpel und schnell 1:1 funktioniert *wink.gif*