微软程序插件式应用开发(管线开发,AddIns)及其复杂性

　　管线开发是微软.Net FrameWork中标准的插件开发方法，按理说它的目的是简化插件式开发，但我觉得它并没有简化，而是显得更复杂化了。除了恼人的视图开发、适配器开发以及目录约定等规则以外，还要更加烦人的调试问题。昨天就遇到一个叫人抓狂的Bug，在首个插件开发完全成功的情况下又进行了几乎完全一样的一个插件开发过程，结果出现了"Unable to cast transparent proxy to type"错误，并且几乎没有任何让可识别的错误，差不多经过整整一天的各种修改也没有找到错误的根源。

　　然而，越是找不到Bug根源，越是想要把它找出来，越是想把它找出来，又越是找不出来，越找不出来就越是抓狂，越是想把它找出来!差不多已经把所有程序代码回退到最简单的状态了！把人急得不行了，并且夜已经很深了，还是上床睡觉先，结果还越想越睡不着。本来这管线开发这么复杂我完全可以不用它，而现在为了一个Bug，反而把我拖进入泥潭中了。一大早起来继续攻关！真真没想到的既然是因为“协定”组件存在于“缩主”程序集目录下的原因！！这个原因导至的是根本无法识别的错误！并且由于管线开发附带了一大堆的组件，根本无法调试到底哪个组件出了问题以及出了什么问题！

　　还有，如果使用插件式开发相当多的类型在管线中根本无法传送，或者需要做非常多的适配器和视图来支持插件，这都给这种形式的插件开发带来麻烦。在codeplex.com上的插件式开发示例也相当复杂，例如有个最新的示例是关于事件(event)在插件(外接程序)和缩主间传递的，编写两端的适配器有超过30多件文件，岂不太复杂了，看看都望而生畏！不过在Viusal studio 2010中也应用了管线开发，例如Microsoft.VisualStudio.Activities.DesignerContract.dll就是一个管线开发协定，不知微软是怎么处理这些组件的复杂性的，不知道微软在开发管理时有没有想到它的复杂性和不便调试性，怪不得现在在网上寻找一些管线开发的资料也非常少，看来用管线开发的还是太少了。或者，是我理解得不够深？希望本文对那些遇到“Unable to cast transparent proxy to type”错误的开发人员有点参考作用。

　　如果上网去查找相关管线开发的资料，除了MSDN外，就是codePlex上的一个项目clraddin，但是这个项目从２００８年７月分开始既然没有更新，并且Pippline Builder有错误，如果利用管线开发插件，对当前来说既没有支持工具，也没有相关更新，真的挺痛苦，再仔细一找，有人（HenKe）也有这个痛苦并重启了一个项目： http://pipelinebuilder.codeplex.com/ 。但不知这个项目以跟微软的项目以后会不会有冲突。