使用託管代碼封裝器從64位託管代碼調用32位非託管代碼的最佳方法

Question

我遇到的情況是必須從託管的64位進程中調用本機32位代碼的頻率隨着64位機器和應用程序的普及而增加。我不想將我的應用程序標記爲32位，並且我無法獲取正在調用的64位版本的代碼。

我當前使用的解決方案是創建C++ COM墊片，這些墊片是從進程中加載​​的，以便從64位進程進行32位調用。

這個COM shim解決方案效果很好，並且跨進程調用由COM處理，這最小化了這種方法的開銷。

但是我想保留所有使用C＃進行的新開發，並想知道是否有任何框架可以最大限度地減少這樣做的開銷。我已經看過IPCChannel，但我覺得這種方法並不像COM shim解決方案那麼簡單。

感謝， 埃德

Answer 1

我有同樣的問題，我的解決方案是使用remoting。基本項目包括：

• 平臺無關CalculatorRemote.dll庫與X32 P
  • CalculatorNative內部靜態類/調用方法從MarshalByRefObject其用於從CalculatorNative本機方法衍生
  • RemoteCalculator類;
• 主平臺獨立的C＃文庫（例如Calculator.dll），引用CalculatorRemote.dll，用其私人使用RemoteCalculator類的單援引在需要的地方的X32功能Calculator類;
• x32控制檯應用程序託管RemoteCalculator從CalculatorRemote.dll消耗Calculator.dll通過IpcChannel。

因此，如果主要應用在64位模式下，它是產卵RemoteCalculator主機應用程序和使用遠程的啓動實例RemoteCalculator。 （在x32中，它只使用了一個本地實例RemoteCalculator。）棘手的部分是告訴calculator-host應用程序關閉。

我覺得這比使用COM，因爲更好：

• 您沒有在任何地方註冊COM類;
• 與COM的互操作應該比.NET遠程處理慢;
• 有時候，如果COM端發生問題，您需要重新啓動應用程序才能從中恢復; （可能我對COM不太熟悉）
• 在x32模式下運行時，遠程處理不會有任何性能損失 - 所有方法都將在同一AppDomain中調用。

Answer 2

幾乎是唯一的答案是出於進程通信的。您可以創建一個.NET項目，這是一個32位可執行文件，它可以完成所有需要的32位調用，並通過Windows消息，WCF，命名管道，內存映射文件（4.0）等與它進行通信。我很確定這就是Paint.NET如何從64位進程中完成他們的WIA（Windows圖像採集）。

在PDN的情況下，他們只是傳遞他們期望的文件的名稱作爲輸出，但更復雜的通信並不困難。這可能是一個更好的方式去取決於你在做什麼。