處理kludgy接口層次結構（MSHTML）的最佳方法是什么？

Question

我正在使用C＃4.0中的MSHTML API ，運行代碼的后勤工作不是問題。 但是，由於設計MSHTML和/或COM接口的方式，編寫代碼很麻煩。 具體來說，應該有一個接口層次結構。 例如， IHTMLDocument7不會擴展IHTMLDocument6 ，它不會擴展IHTMLDocument5 ，依此類推（不過， IHTMLDocument2確實擴展了IHTMLDocument ）。

更令人困惑的是，有一個HTMLDocument接口擴展了DispHTMLDocument （具有DispHTMLDocument IHTMLDocument*接口的所有方法）和HTMLDocumentEvents_Event （提供了一些但不是全部事件）。 更麻煩的是， HTMLDocumentClass是一個協類，它實現了所有上述接口，然后實現了某些接口，例如IDocumentSelector和HTMLDocumentEvents4_Event 。

我真的很希望能夠使用HTMLDocumentClass的API，但是嘗試將其強制轉換為我：

System.InvalidCastException：無法將類型為“ mshtml.HTMLDocumentClass”的COM對象轉換為類類型為“ mshtml.HTMLDocumentClass”的對象。 表示COM組件的類型的實例不能轉換為表示COM組件的不同類型； 但是，只要基礎COM組件支持對接口IID的QueryInterface調用，就可以將它們強制轉換為接口。

另外，某些接口沒有關聯的協類。 例如，有IHTMLElement*接口，但沒有HTMLElement接口，也沒有HTMLElementClass類。 總的來說，我發現很難對接口進行編程。

是否有解決此接口列車殘障的好的技術，還是我應該放棄IntelliSense並在任何地方使用dynamic ？ 我考慮過編寫實現所有接口的包裝器類，但是有太多的MSHTML接口，每個接口都有大量的成員，因此實際的解決方案必須自動化。

Answer 1

IHTMLDocument6不擴展IHTMLDocument5

即使它擴展了IHTMLDocument5，按照COM規則，您仍然應該使用QueryInterface來獲取IHTMLDocument5，而不使用繼承。 我很高興他們沒有讓您想知道如何對包裝類已經實現作為繼承的副作用的接口進行QI。

我建議您在控制對象時不要使用任何包裝器類，並切換到向后兼容的接口。 根據錯誤消息，為IE生成的COM包裝器CLR看起來像是來自不同程序集的mshtml.HTMLDocumentClass類。

在COM編程中，您會經常看到工廠模式。 對於html元素對象，工廠方法為IHTMLDocument2.createElement。 通常，如果作者選擇使用此模式，則無法自行創建對象。

如果存在，Visual Studio會自動引用PIA，否則它會使用tlbexp.exe生成以“ Interop”為前綴的互操作程序集。 但是，大多數情況下，您會在PIA中使用少量接口，因此您可以編寫自己的互操作類型（或從Google Code Search復制）並使用這個大型程序集。