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

Question

我需要從托管的64位進程調用本機32位代碼的情況越來越頻繁，因為64位計算機和應用程序變得普遍。 我不想將我的applciation標記為32位，我無法獲得正在調用的64位版本的代碼。

我目前使用的解決方案是創建C ++ COM填充程序，這些填充程序在進程外加載以從64位進程進行32位調用。

這個COM填充程序解決方案運行良好，跨進程調用由COM在幕后處理，這最大限度地減少了這種方法的開銷。

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

謝謝，艾德

Answer 1

我有同樣的問題，我的解決方案是使用遠程處理 。 基本上該項目包括：

• 與平台無關的CalculatorRemote.dll庫
  • CalculatorNative內部靜態類，帶有x32 P / Invoke方法
  • RemoteCalculator類派生自MarshalByRefObject ，它使用來自CalculatorNative本機方法;
• 獨立於主平台的C＃庫（例如Calculator.dll ），引用CalculatorRemote.dll ，帶有Calculator類，它私下使用RemoteCalculator類的singleton來調用需要的x32函數;
• x22控制台應用程序，它通過IpcChannel從CalculatorRemote.dll托管RemoteCalculator以通過Calculator.dll使用。

因此，如果主應用程序在x64模式下啟動，則會生成RemoteCalculator主機應用程序並使用遠程RemoteCalculator實例。 （在x32中它只使用了RemoteCalculator的本地實例。）棘手的部分是告訴計算器主機應用程序關閉。

我認為這比使用COM更好，因為：

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

Answer 2

幾乎唯一的答案就是流程外的溝通。 您可以創建一個32位可執行文件的.NET項目，該項目需要進行所有32位調用，並通過Windows消息，WCF，命名管道，內存映射文件（4.0）等與之通信。我非常確定這就是Paint.NET如何通過64位進程進行WIA（Windows Imaging Acquisition）。

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