《西游记》中真假美猴王让人着实难以区分，但是我们熟知了其中的细节也不难把他们剥去表象分别出来。对问题不太关心的可以直接调到文中关于.Net文件版本的介绍
问题
最近在编译AKKA.net 时出现了一个问题：Newtonsoft.Json.dll 冲突.
C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(1819,5): warning MSB3243: No way to resolve conflict between "Newtonsoft.Json, Version=7.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed" and "Newtonsoft.Json, Version=4.5.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed". Choosing "Newtonsoft.Json, Version=7.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed" arbitrarily.
Consider app.config remapping of assembly "Newtonsoft.Json, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed" from Version "4.5.0.0" [C:\Program Files (x86)\Microsoft Visual Studio 12.0\Blend\Newtonsoft.Json.dll] to Version "7.0.0.0" [D:\TestProjects\GitHub\akka.net\src\packages\Newtonsoft.Json.7.0.1\lib\net45\Newtonsoft.Json.dll] to solve conflict and get rid of warning.
解决
分析问题
在VisualStudio给出的错误提示中，第一句话着实让人摸不着头脑。还好第二句给出冲突Dll文件的具体路径。但是奇怪的的是明明通过以下命令：
获取的Newtonsoft.Json.dll 应该是 “7.0.1”版本，怎么出来让remaping 到 “7.0.0”版本。
奇怪啊！！
核实Nuget到Newtonsoft.Json.dll
打开Dll文件核实下：
双击“1 [Neutral]”图标，将会打开dll程序集的详细信息如下：
原来Assembly的确是“7.0.0.0”
那好吧，我们再来看下Blend 下的同名文件
Blend文件夹下的Newtonsoft.Json.dll
Assembly Version 4.5.0.0 这和上面7.0.0.0完全不一样啊，VisualStudio（VS）怎么会把他们混淆了？？
尝试解决
让我们来猜下原因吧，那是不是VS找不到具体的7.0.0 的Dll呢，然后就找到了4.5.0 的DLL，结果就…??
打开报错的项目，先卸载项目，然后才可以编辑查看项目文件：
打开项目
发现有两个地方出现了Newtonsoft.Json :
在查阅过<choose>这个不常用节点的用法后，我猜这个是因为这个节点导致，于是直接Ctrl+H 替换成于Reference相同的路径，编译，成功通过！
问题延续
三个重要的.Net 程序集版本
在.Net中有三个重要的版本信息，因为经常混淆，所以要大家注意：
// Assembly mscorlib, Version 2.0.0.0
[assembly: AssemblyFileVersion("2.0.50727.3521")]
[assembly: AssemblyInformationalVersion("2.0.50727.3521")]
[assembly: AssemblyVersion("2.0.0.0")]
版本信息的四部分，我们约定为Major Version（主版本）, Minor Version（次版本）, Build（编译版本）, and Revision（修订版本）
AssemblyFileVersion
通常我们会手动设置 AssemblyFileVersion 中的Major和Minor 去体现程序集的版本，Build 和（或者） Revision 这两个一般是由Build工具在每次编译程序集时自动增加的。 我们可以用AssemblyFileVersion来作为程序集的唯一标识。（调试的时候我们就可以根据这个版本号找到相应dll，）
在项目开发中一般我们会用ChangeList（变更集）号去生成AssemblyFileVersion 的Build和Revision两部分。这样就很方便从dll找到相应的源代码变更集。省去了自己单独去记录发布的dll和源代码对应关系的繁琐事项。
AssemblyFileVersion 存储在Win32的版本资源中，所以可以通过资源浏览器（右击属性）查看程序集的相应AssemblyFileVersion 。
The CLR does not care about nor examine the AssemblyFileVersion.
AssemblyInformationalVersion
AssemblyInformationalVersion 目的是用于整个产品（某个dll或者exe）能够有一个一致的（coherent）版本。这个产品可能含有很多个程序集，而且这些程序集可能有不同的版本标识策略或者根本不是同一个团队开发的。
“For example, version 2.0 of a product might contain several assemblies; one of these assemblies is marked as version 1.0 since it’s a new assembly that didn’t ship in version 1.0 of the same product. Typically, you set the major and minor parts of this version number to represent the public version of your product. Then you increment the build and revision parts each time you package a complete product with all its assemblies.”
— Jeffrey Richter, CLR via C# (Second Edition) p. 57
The CLR does not care about nor examine the AssemblyInformationalVersion.
AssemblyVersion
AssemblyVersion 存储在AssemblyDef的元数据列表清单，任何引用该AssemblyVersion 版本的dll（.exe）。
The AssemblyVersion is used by the CLR to bind to strongly named assemblies.（CLR唯一关心的版本）
这一点至关重要,只有AssemblyVersion版本完全一致的（匹配的）强命名程序集，才能编译成功。例如，如果你引用了一个1.0.0.0的强命名A.dll，编译后，你将A.DLL升级到了1.0.0.1.那么，不好意思，你的程序将会失败，那就没有办法了吗？有可以参考Assembly Binding Redirection 来做DLL重定向。
小心修改AssemblyVersion
当别的开发人员正在引用你发布的程序集是，你应该非常小心的去修改这些程序集的AssemblyVersion。AssemblyVersion的任何改动都意味着开发者不得不重新编译应用程序（或者相应的dll）而不是简单的直接文件覆盖（新版本dll直接覆盖就版本dll）。
- 如果要保证当前发布的dll向后兼容，请不要修改AssemblyVersion。
- 如果你有突破性的修改（脱胎换骨的大改动），那请修改AssemblyVersion。
总结
有的同仁总觉得.Net简单，GC帮我做了好多内存管理工作，我们就可以随心所欲，为所欲为。且不知任何技术都有他不可告人的软肋，广告总是大篇幅的说着自己的完美哪有功夫给大家展示自己的不足（当然这里很多时候涉及到了设计准则哲学，如框架设计会优先考虑20%的经常使用功能，而暂缓考虑其他的80%不常用的功能）。
所以学习一门技术一定要知道他的底层原理和关键点。知道的越多，你被坑的概率就会越少，效率就越高。
参考
Newtonsoft.Json Assembly Conflict
《CLR Via C#》