2009-12-11 103 views
3

我們開發了一套由C#開發的對象組成的S/W體系結構。他們廣泛使用事件來通知客戶狀態的變化等。從非託管C++調用託管代碼(c#)的最佳方法

最初的意圖是允許傳統代碼通過COM互操作服務使用這些管理對象。這在設計規範中很容易寫出來,但是,我發現實際執行它更成問題。我已經搜索了很多小時,尋找一個使用這種方法處理事件的好例子。在我們走上這條路之前,我想確保COM互操作是允許遺留代碼調用我們新代碼的最佳方式。

它看起來有幾種不同的選擇:1)COM互操作,2)編寫非託管包裝類3)使用/ clr編譯器開關啓用託管對象的調用,4)使用某種反向pInvoke調用。我錯過了嗎?

每個選項都有其優點&的缺點,我想知道最好的方法是什麼。這裏是每個具體問題/評論

COM INTEROP - 看來事件處理是一個障礙。我們使用具有變量類型的事件作爲參數。一個事件參數可能有一個事件ID和一個對象。基於事件ID,對象將是特定類型的。這可以通過COM互操作來處理嗎?許多暴露的對象都有屬性。您不能在接口中聲明屬性,因此所有屬性都需要相應的get/set方法。

WRITE UNMANAGED WRAPPER - 我假設這意味着使用/ clr選項創建DLL,以允許創建和調用託管對象並公開非託管對象。這些不受管理的客戶會不會我以前沒有這樣做過。這有什麼好處/缺點?

使用/ CLR開關 - 我理解這意味着添加對託管對象的支持。這種方法有什麼缺點?這個選項是否支持上述的事件?我們可以說,「這裏是託管庫。在你的遺留代碼中使用/ clr編譯器選項並擁有它?我不知道這個的後果。有沒有一個很好的示例說明這是如何工作的? (我確定有,我只是還沒有找到它)

使用反向PINVOKE - 我不確定這將如何工作,但從我已經能夠找到,這不是一個可能的有效解決方

那麼,決策樹是什麼樣子才能找到正確的方向?任何幫助表示讚賞。

  • DP

回答

1

我認爲您最初的解決方案是最好的。 COM互操作性是穩定的和合理有效的記錄。您只需確保所有可能從給定事件處理程序中彈出的不同事件對象實現相同的COM可見基礎事件對象接口(具有事件類型標識符等)。從那裏,單個對象可以實現他們想要的任何其他接口,並且您的非託管代碼可以根據您要定義的任何標準爲正確的「細節」接口提供QI。這真的不那麼難。查看this CodeProject文章,瞭解包括非託管事件處理程序在內的端到端示例。