一 问题的出现
现在要做一个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注册过程