记一次dll强命名冲突事件

一  问题的出现

   现在要做一个net分布式平台,平台涉及多个服务之间调用问题,最基础的莫过于sso。由于我们的sso采用了wcf一套私有框架实现,另外一个webapi服务通过接口调用sso服务。由于sso和webapi都同时采用了

在net平台下广泛使用的序列化库Newtonsoft.Json,虽说他是开源的。,但是被不同的dll依赖过后会带有强命名。这个时候sso使用了Newtonsoft.Json强命名a,而webapi的system.web.http使用了Newtonsoft.Json强命名b

这个时候webapi又使用了我们的私有框架,又使用了webapi相关dll,他们都共同依赖Newtonsoft.Json这个序列化库,但是呢他们依赖的强命名却不同,这个时候就产生了dll冲突。

二 背景知识

  强命名的概念:我们都知道一个dll有文件名,版本号,语言,公钥等关键元数据信息组成,在net中强命名就是这几个元数据组合而形成的一个标识,这个标识就是强命名,他的意图就是要唯一性的标识一个dll文件。

至于为什么要强命名一个dll,可以百度下dll hell也就是dll地狱相关资料。这个强命名中最能够唯一化的就是公钥也就是publikeytoken,他是通过我们的snk,加密生成的一个公钥私钥对,私钥存储在程序集清单中,用于加密,而公钥用于解密和发布dll。由于公有私有采用rsa非对称加密算法,所以理论上这个公有和私有是唯一的。

  强命名与弱命名引用关系:微软规定强命名的dll所依赖的dll也必须是强命名的,反之不是这样,弱命名所依赖的dll可以是强命名也可以是弱命名。如GAC中的dll均是强命名,而我们一般开发的应用程序没有强命名也正常运行。

 

 

三 dll依赖关系梳理

 

 

从这个图中梳理出产生了dll冲突的原因所在,那么自然就有了解决办法。

 

四 解决思路

    第一种办法:由于微软提供的dll使用了强命名Newtonsoft.Json,这里是私有基础库只有来适应微软,我们统一使用Newtonsoft.Json编译整个基础库,万幸问题得以解决。

    第二种办法如果我们的三方库再有像webapi一样又依赖了强命名的Newtonsoft.Json C且没有源码这个时候就难办了啊,但是这种情况该是不多吧~~,如果真出现了估计得改变技术方向了,这里的服务之间采用的是net程序集接口直接调用方式,如果真有第三种情况出现,那么这种接口方式估计得换成webapi方式,直接将服务的接口进行物理层隔离。所有服务之间交互通过webapi接口实现,在物理上隔离,统一协议进行协作了。

   第三种办法:学习GAC思路,GAC的一个dll也会对应多个版本,所以可以考虑将dll注册到GAC,所不同的是需要有一个GAC注册过程

 

 

posted @ 2017-07-05 11:15  cuit_igis  阅读(343)  评论(0编辑  收藏  举报