Die beste Methode zum Aufrufen von 32-Bit-nicht verwaltetem Code aus 64-Bit-verwaltetem Code mithilfe eines verwalteten Code-Wrappers

Question

Die Häufigkeit, mit der ich auf die Situation stoße, in der ich nativen 32-Bit-Code von einem verwalteten 64-Bit-Prozess aufrufen muss steigt mit der Verbreitung von 64-Bit-Maschinen und -Anwendungen. Ich möchte meine Anwendung nicht als 32-Bit markieren, und ich kann keine 64-Bit-Versionen des Codes erhalten, der gerade anruft.

Die Lösung, die ich derzeit verwende, ist das Erstellen von C++ - COM-Shims, die aus dem Prozess geladen werden, um die 32-Bit-Aufrufe aus dem 64-Bit-Prozess zu machen.

Diese COM-Shim-Lösung funktioniert gut und die Cross-Prozessaufrufe werden von COM hinter den Kulissen abgewickelt, was den Overhead dieses Ansatzes minimiert.

Ich möchte jedoch alle neuen Entwicklungen behalten, die wir mit C# durchführen, und wir haben uns gefragt, ob es Frameworks gibt, die den Aufwand dafür minimieren. Ich habe IPCChannel angeschaut, aber ich denke, dass dieser Ansatz nicht so sauber ist wie die COM-Shim-Lösung.

Dank, Ed

Answer 1

Ich hatte das gleiche Problem und meine Lösung war remoting zu verwenden. Grundsätzlich ist das Projekt bestand aus:

• plattformunabhängige CalculatorRemote.dll Bibliothek
  • CalculatorNative interne statische Klasse mit X32 P/Invoke Methoden
  • RemoteCalculator Klasse von MarshalByRefObject abgeleitet, die verwendet nativer Methoden aus CalculatorNative;
• Hauptplattformunabhängige C# Bibliothek (z.B. Calculator.dll), Referenzieren CalculatorRemote.dll mit Calculator Klasse, die privat Singletons der RemoteCalculator-Klasse wurde x32 Funktionen aufzurufen, wo erforderlich;
• x32-Konsole-Anwendung, die RemoteCalculator von CalculatorRemote.dll gehostet von Calculator.dll über IpcChannel zu konsumieren.

Also, wenn die Hauptanwendung begann im x64-Modus wurde eine RemoteCalculator Host-Anwendung Laichen und verwendete remoted RemoteCalculator Instanz. (In x32 verwendete es nur eine lokale Instanz von RemoteCalculator.) Der schwierige Teil war, Rechner-Host-Anwendung zu sagen, herunterzufahren.

Ich denke, das es besser als COM verwenden, weil:

• Sie müssen COM-Klassen überall nicht registrieren;
• Interoperation mit COM sollte langsamer als .NET-Remoting sein;
• Manchmal, wenn etwas auf der COM-Seite schief geht, müssen Sie Ihre Anwendung neu starten, um davon zu erholen; (möglicherweise bin ich nur mit COM nicht sehr vertraut)
• Wenn im x32-Modus ausgeführt wird, gibt es bei Remoting keine Leistungseinbußen - alle Methoden werden in derselben AppDomain aufgerufen.

Answer 2

So ziemlich die einzige Antwort ist die Kommunikation außerhalb des Prozesses. Sie könnten ein .NET-Projekt erstellen, bei dem es sich um eine 32-Bit-ausführbare Datei handelt, die alle 32-Bit-Aufrufe benötigt und mit Windows-Nachrichten, WCF, Named Pipes, Memory Mapped Files (4.0) usw. kommuniziert So macht Paint.NET ihre WIA (Windows Imaging Acquisition) aus einem 64-Bit-Prozess.

Im Fall von PDN übergeben sie einfach den Namen der Datei, die sie als Ausgabe erwarten, aber komplexere Kommunikation ist nicht schwierig. Es könnte ein besserer Weg sein, abhängig davon, was du tust.