标签:
《西游记》中真假美猴王让人着实难以区分,但是我们熟知了其中的细节也不难把他们剥去表象分别出来。对问题不太关心的可以直接调到文中关于.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”版本。
奇怪啊!!
Newtonsoft.Json.dll
打开Dll文件核实下:
双击“1 [Neutral]”图标,将会打开dll程序集的详细信息如下:
原来Assembly的确是“7.0.0.0”
那好吧,我们再来看下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中有三个重要的版本信息,因为经常混淆,所以要大家注意:
// 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 中的Major和Minor 去体现程序集的版本,Build 和(或者) Revision 这两个一般是由Build工具在每次编译程序集时自动增加的。 我们可以用AssemblyFileVersion来作为程序集的唯一标识。(调试的时候我们就可以根据这个版本号找到相应dll,)
在项目开发中一般我们会用ChangeList(变更集)号去生成AssemblyFileVersion 的Build和Revision两部分。这样就很方便从dll找到相应的源代码变更集。省去了自己单独去记录发布的dll和源代码对应关系的繁琐事项。
AssemblyFileVersion 存储在Win32的版本资源中,所以可以通过资源浏览器(右击属性)查看程序集的相应AssemblyFileVersion 。
“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 存储在AssemblyDef的元数据列表清单,任何引用该AssemblyVersion 版本的dll(.exe)。
当别的开发人员正在引用你发布的程序集是,你应该非常小心的去修改这些程序集的AssemblyVersion。AssemblyVersion的任何改动都意味着开发者不得不重新编译应用程序(或者相应的dll)而不是简单的直接文件覆盖(新版本dll直接覆盖就版本dll)。
有的同仁总觉得.Net简单,GC帮我做了好多内存管理工作,我们就可以随心所欲,为所欲为。且不知任何技术都有他不可告人的软肋,广告总是大篇幅的说着自己的完美哪有功夫给大家展示自己的不足(当然这里很多时候涉及到了设计准则哲学,如框架设计会优先考虑20%的经常使用功能,而暂缓考虑其他的80%不常用的功能)。
所以学习一门技术一定要知道他的底层原理和关键点。知道的越多,你被坑的概率就会越少,效率就越高。
Newtonsoft.Json Assembly Conflict
《CLR Via C#》
标签:
原文地址:http://www.cnblogs.com/HQFZ/p/5000038.html