Registration-Free COM Interop und abhängige Assemblies

Wir arbeiten an einer Integration einer großen MFC-basierten Anwendung mit einer Handvoll verwalteter (.NET) Add-Ins. Die Kommunikation mit diesen Add-Ins erfolgt über COM.Registration-Free COM Interop und abhängige Assemblies

In der Vergangenheit haben wir die Registrierung nur verwendet, um diese Add-Ins (als COM-Server) für die Anwendung verfügbar zu machen. Aber jetzt versuchen wir, registrierungsfreie COM-Interop zu verwenden, um dies zu tun.

Wir möchten, dass diese Add-Ins in einem separaten Verzeichnis von demjenigen, in dem die Anwendung ausgeführt wird, leben können - idealerweise überall. Aber wir stoßen anscheinend auf Probleme mit der Instanziierung der Serverobjekte, da abhängige Assemblys, die ebenfalls im Verzeichnis mit der COM-Server-DLL leben, nicht aufgelöst werden können.

"Old-fashioned" COM Interop behandelt dies mithilfe eines LoadFrom-Kontext beim Laden der Zielbaugruppe. Aber der Aktivierungskontextmechanismus scheint dies nicht zu tun.

Weiß jemand, wie man das zur Arbeit bringt? Es ist nicht klar, ob abhängige Assemblys im SxS-Manifest des Moduls identifiziert werden können oder ob wir den Aktivierungskontext möglicherweise anders erstellen können.

Danke für irgendwelche Gedanken/Tipps!

Jeff

Quelle

2009-10-29 Jeff

Haben Sie eine Lösung dass' finden? – RayOldProf

Hoffnung verstehe ich das Problem, da ich nicht so vertraut mit einem MFC-Projekt bin noch es Einschränkungen. Wie wäre es mit einer "bekannten" .NET-Klasse mit einer Schnittstelle (dauerhaft bei der MFC-App registriert), die wiederum alle Aktivierung und Instanziierung übernimmt?

Rodney

Quelle

2009-12-22 06:40:25 Rodney

Dies ist tatsächlich ein Workaround, der erfolgreich war: Wir erstellen ein C++/CLI-Modul, das registrierungsfrei aktiviert werden kann, und wir verwenden es, um die C# -Klasse zu instanziieren. Damit dies funktioniert, müssen wir auch einen AssemblyResolve-Event-Handler einrichten, damit abhängige Assemblies im selben Verzeichnis gefunden werden können. Das ist OK, aber ist irgendwie klobig. Es scheint, dass dies in der Lage sein sollte, ohne diese zusätzliche Ebene der Indirektion zu arbeiten. – Jeff

-1

Haben Sie registriert intermediär (Interop) dlls mit .net Framework?

C: \ WINDOWS \ Microsoft.NET \ Framework \ v2.0.50727 \ regasm "Pfad .. \ AxInterop.xxx.dll" oder C: \ WINDOWS \ Microsoft.NET \ Framework \ v2.0.50727 \ regasm „Pfad .. \ Interop.xxx.dll“

Grüße Phani

Quelle

2009-12-23 07:49:22 Phanidhar

Danke für den Kommentar, Phani. Der entscheidende Punkt dabei ist, die Registrierung zu vermeiden. – Jeff

Als ich im Artikel sehen Simplify App Deployment with ClickOnce and Registration-Free COM ich nehme zur Kenntnis, dass sie den Dateinamen der Registrierung frei COM-Objekt-DLL im Anwendungsmanifest verweisen. Ich vermute, dass dieser Dateiname geändert werden könnte, um ein Verzeichnis oder ähnliches einzuschließen.

Zweitens enthalten sie im Abschnitt "Ein komplexeres Beispiel" abhängige COM-Objekte als Verweise auf ihr Projekt und legt sie als isoliert fest. Das heißt, sie sind jetzt auch registrierungsfrei. Meine Vermutung ist, dass ihr Weg auch aktualisiert werden könnte.

Quelle

2009-12-23 11:12:33

Wir haben nicht wirklich den Luxus, das Anwendungsmanifest zu modifizieren, da die hier geladenen Assemblies "Add-Ins" sind und nachträglich hinzugefügt werden können. Es ist möglich, dass etwas mehr im Modulmanifest die Antwort hier ist, aber nichts, was wir versucht haben, hat funktioniert - es scheint "nur" ein Problem mit den Ladealgorithmen von .NET zu sein. – Jeff

-1

öffnen Sie Ihre Visual Studio-Eingabeaufforderung und versuchen, die Assembly registrieren mit regasm

regasm /tlb:"path"

Quelle

2009-12-23 12:34:32 shahjapan

Wie ich oben erwähne, wollen wir nichts registrieren. Dies würde die Typbibliothek einschließen. Außerdem ist in diesem Fall die Typbibliothek für die von uns implementierte Schnittstelle bereits registriert. – Jeff

Registration-Free COM Interop und abhängige Assemblies

Antwort

Verwandte Themen