上一章，我们讲解了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合并