上一章，我們講解了Interop的引用錯誤和修改方法，本章開始引出新的問題。

每當想生活再好點，新問題就出來了

繁多的Interop，還要雨露均沾

上文已經找到并解決了Interop錯誤問題，此時就可以開開心心的引用這些勞動成果，并編譯出我們心愛的C#項目。可是每次我們想發版給客戶的時候，都會非常郁悶，因為編譯后的文件，簡直多的可怕。比如下面這個截圖，做了一個小的不能再小的項目了，U8登錄加標準單據保存功能。結果一大堆文件，你說嚇人不！

如果可以忍受這樣的發版目錄，那么沒問題，直接拷貝給客戶，運行就好了。但是強迫癥的我，必須想想辦法，我可不想在如此多的文件里面找可執行程序，最好目錄更干凈一些，C#項目引用也干凈一些，不想每次都引用一大堆的Interop。畢竟開發的項目很多，如果每一個項目都引用一大堆鬼Interop，實在是崩潰。

我的項目到底是啥U8版本的Interop,我想不起來了

還有一個問題，就是這些Interop在用友的各個版本里面都是一樣名字，如果時間久了，你很難記住你這個項目是哪個版本的，很容易造成舊版在新系統環境中運行，結果GUID不一致，造成COM初始化失敗。所以我們才經常遇到一種報錯說{XXX-XXX-XXXX-一個長長的GUID}不能類型轉換或者初始化失敗。比如你的代碼編寫時還是V11.0，后來想在V13.0里面跑，結果解決方案中的Interop替換不完整。結局就莎士比亞了！

U8本身的Interop越來越多，且開始出現同DLL多版本了

你去U8的Interop下面看看，如此之多的Interop，看著都眼暈。這我也就忍了，如果你翻看其他目錄，會發現居然也有Interop文件，換言之，總部沒有完全控制住Interop文件的統一性。

比如C:U8SOFTU8KCSNin這個目錄，就出現了一批新的Interop。這個目錄是條碼功能的web服務，這個目錄里面的代碼建議大家反編譯以后好好研究一下，寫的好不好我不敢評論，但是這是我唯一找到的全部使用C#開發的U8功能，而且還是WEB版本的。里面包裝了好多U8庫存單據的保存功能代碼，他沒有調用U8 API，而是使用Interop技術直接調用COM功能，他保存的單據支持貨位，序列號，上下游單據咬合等功能，所以研究價值很高。最核心的代碼都在Barcode.SV.DataAccess.DLL里面。

問題要解決，思路很重要

列出問題

上面的Interop新問題，這里總結一下：

1、Interop在各個U8版本中同名，但是COM組件在各個U8版本中GUID會變，造成舊的Interop不能在新環境下使用，必須重新引用編譯。
2、繁多的Interop，讓你的項目在重新引用的時候，非常麻煩，而且容易出錯。
3、當想復用別的模塊中現成的DLL時，發現總部的Interop已經出現多版本了。如果去引用這些勞動成果，又會出現前文提到的同名文件不同強命名問題。

先說理想，再想方案

寫到這里，我特別想說，總部這幫哥們天天都在干什么，能不能搞搞底層建設，開源開源業務代碼。天天蹲在屋子里面，不是改BUG，就是在增加新需求。就不能給我們二開留一口吃飯的地方嗎？搞一個API吧，BO對象里面的字段各種錯誤，讓二開回歸使用DOM法，一個單據一百多個字段，我上哪知道那個字段是什么。搞一個EAI，不能上下游單據咬合，就能導入個憑證BOM和訂單。好容易好容易憋出來一個OpenAPI，結果還是EAI的變體，還要繞一大圈廣域網來調用，性能不敢恭維。
如果U8能夠趨向于平臺閉源，加開源業務模塊，那么總部就能從BUG解決中釋放出來，讓更多的伙伴去提供開源的業務模塊功能，去修改現有模塊中的錯誤。人多力量大，非要吃獨食，說多了，回歸正題。
針對上面的三個問題，我最理想的效果是這樣：

1、Interop文件以某種功能或者分類，進行大合并，將現有的多個Interop合并到一個或者幾個DLL中。
2、類名的命名規則必須出現版本號，例如COMV1300_U8Login.clsLogin，最大化規避版本錯亂問題，當然這也帶來了代碼需要更新的問題，這個我也想過，只要批量替換COMV1300_就好了，完全可以通過命名規則搞定。
3、只要有了1和2，基本所有問題就能解決了，因為如果我可以引用COMV1300的dll和其他的原廠interop，由于類名已經變成不一樣的了，就沒有了重名問題。只要在代碼里面使用類型強制轉換就可以將我的COM實例，送給其他的Interop類了。

我們就把這個理想叫做Interop合并方案吧

本章完

下一章，介紹如何進行Interop合并

總結

以上是生活随笔為你收集整理的如何使用C#调用U8的COM组件之三 繁多的Interop的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。