[erledigt] Generischer Aufruf des AddIn Frameworks über COM

Hallo Zusammen,

ich muss euch mit einem etwas "wilden" Konstrukt meinerseits konfrontieren.

Ich habe eine externe Anwendung welche man um Funktionalität anreichern kann, leider geht dies nur über FunctionCalls also COM. Somit muss meine DLL im GAC liegen um Com-Aufrufbar zu sein.

Wenn ich nun die DLL im GAC um eine Funktion anreichere, muss diese durch den kompletten Testpool der Firma um dann nach 1-2 Monaten auf die Clients bestrahlt zu werden.
Jetzt war mein Ansatz das die DLL im GAC nur eine "Weiterleitung" auf eine lokale DLL darstellt (welche ich beliebig austauschen kann).

Also dass ich in der DLL im GAC eine folgende Methode anbiete:
CallFunction(string strClass, string strMethod, strParam1, strParam2 .... strParamN);

Welche dann wiederum eine die Host DLL des AddIn Frameworks ruft, welche dann generisch die richtige Assembly findet (strClass), diese instanziiert und die richtige Methode (strMethod) mit den Parametern ruft.

Funktioniert auch soweit. Jedoch gibt es ein Problem bei folgendem Aufruf:

var addinInstance = addinToken.Activate<object>(AddInSecurityLevel.FullTrust); 

Und zar beim Parametet <T> (hier >object>) der Activate Methode. Das AddIn-Framework schreibt hier den Typ der zu rufenden Assembly vor. Die Assembly hab ich auch, nur wie kann ich hier zur Laufzeit den Typ definieren?

Ich hoffe es war verständlich wie das Vorgehen ist, für alternativ Vorschläge bin ich seeehr offen, aber im Moment scheint es so als wäre dies die einzige Lösung....

So ganz habe ich das nicht verstanden, was Du machst....Aber wieso definierst Du nicht einfach ein Interface, dass Deine Objekte implementieren und benutzt dann an dieser Stelle das Interface?

Hi,

benutzt du dazu das AddIn-Framework von .Net (System.AddIn)?
Weiß jetzt nicht genau, ob das in so einem Szenario sauber funktioniert bzw. getestet ist. Ich persönlich würde versuchen, über das MEF oder eine recht pragmatische Lösung per Assembly.Load(...) zu gehen.

Gruß
Roland

Hallo mo#,

weder deine Beschreibungen, noch der Titel sind sehr präzise... Allein schon solche Aussagen wie "leider geht dies nur über FunctionCalls also COM".
Was du machen willst, ist ja eigentlich nur ein Hack. Du willst die Deployment Politik deiner Firma (oder des Kunden) durch eine technische Lösung umgehen. Ich glaube nicht, dass es Sinn der Sache war, kann aber schon sein, dass es sich in dem Fall anbietet.
Zu deiner Frage. Das T in der Activate Methode kann auch eine Schnittstelle sein. Und an der Stelle spielt es auch keine Rolle, ob du das "über COM" aufrufst oder nicht. Du rufst es ja nicht über COM auf, die Funktion, die das aufruft, wird über COM angestoßen, aber das spielt ja keine Rolle.
Genauer will ich auf das ganze jetzt eigentlich gar nicht eingehen... Die Schnittstelle CallFunction(string, string, string, string, string) ist sicher nicht besonders sauber oder typsicher. Es gibt sehr viele Möglichkeiten, das besser zu lösen.

weder deine Beschreibungen, noch der Titel sind sehr präzise... Allein schon solche Aussagen wie "leider geht dies nur über FunctionCalls also COM".

Wie kann ich die Tatsache präzisieren das die rufende Anwendung nur über COM Kommunizieren kann?

Was du machen willst, ist ja eigentlich nur ein Hack. Du willst die Deployment Politik deiner Firma (oder des Kunden) durch eine technische Lösung umgehen. Ich glaube nicht, dass es Sinn der Sache war, kann aber schon sein, dass es sich in dem Fall anbietet.

Nein ich muss die Deploymentfähigkeit von "Zentral gesteuert, weil WIn Komponente betroffen" auf "Dynamisch gesteuert weil Anwendungsspezifisch" ändern. Ich sehe hier keinen "Hack", es ist die normale Umsetzung einer Anforderung.

Zu deiner Frage. Das T in der Activate Methode kann auch eine Schnittstelle sein. Und an der Stelle spielt es auch keine Rolle, ob du das "über COM" aufrufst oder nicht. Du rufst es ja nicht über COM auf, die Funktion, die das aufruft, wird über COM angestoßen, aber das spielt ja keine Rolle.

Hat sich inzwischen erledigt. Wir haben das AddIn Framwork an der Stelle noch nicht richtig verstanden gehabt. Wir brauchen da den Typ des AddIn.Views und nicht des AddIns.
Der Zusammenhang mit COM hat sich ergeben weil es bei dem entsprechenden Entwickler bei einem normalen Aufruf funktioniert hat und bei einem COM-Aufruf nicht, was aber mit der Erreichbarkeit der DLLs zu tun hat.

Genauer will ich auf das ganze jetzt eigentlich gar nicht eingehen... Die Schnittstelle CallFunction(string, string, string, string, string) ist sicher nicht besonders sauber oder typsicher. Es gibt sehr viele Möglichkeiten, das besser zu lösen.

Dann sag mir mal bitte wie ich aus einer Anwendung - welche keine Typen kennt, über COM was in seiner Typisierung auch sehr eingeschränkt ist eine typsichere, generische Schnittstelle hinbekomme ohne das gros im GAC liegen zu lassen?

Alles in allem ist dein Posting eigentlich nur substanzloses Flaming auf was wohl jeder hier gut verzichten kann.

Sehe ich nicht so.

Lies dir bitte selber dein Eingangsposting durch, und erkläre was an coder007 Aussagen nicht auf das Posting zutrifft?

Wir haben hier nämlich nur die Aussagen aus dem Posting.