. NET DLL conflict resolution "reprint"

Transferred from: http://www.cnblogs.com/HQFZ/p/5000038.html

Recently there was a problem in compiling akka.net: Newtonsoft.Json.dll conflict.

C:\Program Files (x86) \msbuild\14.0\bin\microsoft.common.currentversion.targets (1819,5): Warning Msb3243:no to Resolve conflict between "Newtonsoft.json, version=7.0.0.0, Culture=neutral, Publickeytoken=30ad4fe6b2a6aeed" and "New Tonsoft. 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.

Resolve Analysis Issues

In VisualStudio's error, the first sentence is truly confusing. Fortunately the second sentence gives the specific path to the conflicting DLL file. But the strange thing is that plainly through the following command:

Get the Newtonsoft.Json.dll should be "7.0.1" version, how to come out to let remaping to "7.0.0" version.

Strange Ah!!

Verifying NuGet to Newtonsoft.Json.dll

Open DLL file verification under:

Double-clicking the "1 [Neutral]" icon will open the DLL assembly details as follows:

The original assembly is indeed "7.0.0.0"

Well, let's look at the same name file under Blend.

Under the Blend folder Newtonsoft.Json.dll

Assembly Version 4.5.0.0 This is completely different from the above 7.0.0.0, VisualStudio (VS) how can they confuse them??

Try to solve

Let's guess the reason, it is not the specific 7.0.0 DLL, and then found the 4.5.0 DLL, the result is ...??

Open the error item, uninstall the project before you can edit the View project file:

Open Project

There were two places where Newtonsoft.json were found :

After checking the usage of <choose> this infrequently used node, I guess this is because of this node, so the direct ctrl+h is replaced by the same path as reference, compile, successfully pass!

Problem-related knowledge

What do you want to do with the last pile? I'm sure some people will wonder.

Yes, the purpose of the above toss half a day is to find out the following several about. NET assembly version is of paramount importance, the first contact must be curious (perhaps depressed, because the problem is disturbing).

Three important. Net Assembly versions

There are three important version information in. NET because it is often confusing, so be aware of:

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")]  

Version information in four parts, we agreed to Major version (major version) , Minor version (minor) , build (compiled version), /c12> , and Revision (revised version)

assemblyfileversion

Usually we manually set major and minor in assemblyfileversion to reflect the version of the Assembly, and the build and/or Revision are typically added automatically by the build tool each time the assembly is compiled. We can use assemblyfileversion as a unique identifier for an assembly. (We can find the DLL according to this version number when debugging)

In the project development, we usually use the changelist (changeset) number to generate the assemblyfileversion Build and revision two parts. This makes it convenient to find the corresponding source code changeset from the DLL. Eliminates the tedious matter of documenting the DLL and source-code correspondence that you publish separately.

Assemblyfileversion is stored in the Win32 version resource, so you can view the corresponding assemblyfileversion of the assembly through the Resource browser (right-click Properties).

The CLR does not care about nor examine theAssemblyfileversion .assemblyinformationalversionAssemblyinformationalversion is intended for the entire product (a DLL or EXE) to have a consistent (coherent) version. This product may contain many assemblies, and these assemblies may have different version identity policies or are not developed by the same team at all.

"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 pro Duct. 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 your 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 a list of metadata lists stored in AssemblyDef, any DLL (. exe) that references that assemblyversion version.

TheAssemblyVersionis used by the CLR to bind to strongly named Assemblies. (The only version that the CLR cares about) is critical.

Only the AssemblyVersion version of the fully consistent (matched) Strong-named assembly can be compiled successfully. For example, if you reference a 1.0.0.0 strong named A.dll, after compiling, you will A.DLL upgrade to 1.0.0.1. Then, sorry, your program will fail, then there is no way to do it? You can refer to Assembly Binding redirection to do DLL redirection.

Carefully modify the AssemblyVersion

When other developers are referencing your published assembly, you should be very careful to modify the assemblyversion of these assemblies. Any change to AssemblyVersion means that the developer has to recompile the application (or the corresponding DLL) instead of simply overwriting the file (the new version DLL is overwritten directly on the version DLL).

• If you want to guarantee backward compatibility with the currently published DLLs, do not modify the assemblyversion.
• If you have a groundbreaking change (a big change), please change the assemblyversion .

Summarize

Some of my colleagues always feel. NET simple, GC helped me do a lot of memory management work, we can do whatever you like. And do not know any technology has his hidden weaknesses, advertising is always a big space to say their own perfect which has Kung fu to show everyone's shortcomings (of course, there are many times involved in the design of philosophy, such as the framework design will give priority to 20% of the regular use of functions, and deferred consideration of other 80% less commonly used functions).

So to learn a technology must know his underlying principles and key points. The more you know, the less likely you are to be trapped and the more efficient you will be.

Reference

Newtonsoft.json Assembly Conflict

Choose Element (MSBuild)

Assembly Versioning in. NET

Assembly Binding Redirection

"CLR Via C #"

. NET DLL conflict resolution "reprint"