Net DLL component version compatibility issues

DLL component version compatibility problem is often encountered in production development, common component compatibility issues such as: newtonsoft.json,log4net, etc.

In order to save everyone time, want to see the solution directly, you can directly click on the table of contents 3, 4

Catalogue

1. Reasons for version compatibility issues

2. Resolve version Compatibility Prerequisites

3. Specify a specific version bindingredirect**

4. Specify a specific version of a folder codebase**

Reasons for version compatibility issues

First, let's take a brief look at the principles of the program reference:

When the runtime tries to resolve a reference to another assembly, it begins the process of locating and binding to the Assembly. See more: How the Runtime Locates Assemblies

The steps are as follows:

• 1th Step: Check the configuration file (. config file)
• 2nd step: Check the previously referenced assembly
• 3rd Step: Check the Global assembly cache
• 4th Step: Locating the assembly by base code or probing

Resolve version Compatibility Prerequisites

After a simple understanding of the principles, common solutions to compatible methods

1. First understand what you want to use that DLL, what the specific version is, view the version method:

1) folder in DLL file, right-click Properties

2) DLL referenced in solution, right-click Property

Method 1, specify a specific version * *

Using Config's bindingredirect to point to a specific version of the component

. config Add node

<Configuration><Runtime><assemblybindingxmlns= "Urn:schemas-microsoft-com:asm.v1"><dependentassembly><assemblyidentityname= "Newtonsoft.json"PublicKeyToken= "30ad4fe6b2a6aeed"Culture= "neutral" /><BindingRedirectoldversion= "0.0.0.0-10.0.0.0"newversion= "10.0.0.0" /></dependentassembly></assemblybinding></Runtime></Configuration>

Explanation:

All projects in the project, class Library Reference 0~10 version Newtonsoft.json, and eventually point to 10 this version

Experience:

1, the version between the code changes, if a class library with a component 10.0 of the A10 method, the results point to the 8.0,8.0 is likely to have not A10 this method, natural projects used in the A10 of the place will be error. Debugging and error checking are cumbersome, and the compiler will match the code to call method and property hint errors based on the DLL version below the bin, or do not prompt for errors.

2, the code can be controlled place, as far as possible to update the version of the obsolete method into a higher version of the alternative method.

3, the general high version of the majority is compatible with the low version of the method, pointing to the high version of this newspaper error is smaller, of course, there are special circumstances.

Method 2, specify a specific version of a folder

Method One solves the issue of versioning in many projects, but sometimes there are some strange compatibility issues to be encountered.

For example: Log4net and Memcached.clientlibrary in the log4net conflict problem, this article to resolve this version of the conflict problem as an example of how to use this method.

If you want to see the results directly, please click on the workaround

Why does the Log4net version compatibility issue occur?

Common components are made up of name (name), version (s), PublicKeyToken (public key) three, due mainly to the difference between log4net version 1.2.11 and 1.2.10 PublicKeyToken.

You can view the public key using the VS tool Sn-t component filename. dll .

Log4net (≥1.2.11) Public key is marked as 669E0DDF0BB1AA2A

Log4net (= 1.2.10) public key is marked as 1b44e1d426115821

See log4net in the development process of the identity card, and a lot of older versions of the component references to the low version of log4net resulting in compatibility issues with the high version

Examples of log4net version compatibility issues 1. Create project, reference memcached component

WebApp is the project application layer, ClassLibrary is the tool class library, WebApp references ClassLibrary project, ClassLibrary introduces Memcached.clientlibrary 1.0 components through NuGet.

ClassLibrary create the class Testing.cs code as follows:

     Public class Testing    {        publicstaticvoid  Init ()        {            new  Memcachedclient ();        }    }

webapp Create the test page and test the code as follows:

Testing.init ();

2, Application layer, reference high version log4net

WebApp References Log4net 2.0.8

The final project situation is:

3. Operation Result

The log4net version under the Bin folder of the WebApp is 2.0.8, and the log4net for the Memcached.clientlibrary component is 1.2.10.0, so the error has been made.

Attention

If compiled separately Webapp,bin below is the version is 2.8.0, if the ClassLibrary class library is compiled separately, the following version of Bin is 1.2.10.0

Handling Log4net Version compatibility issues

1. Add the log4net1.2.10.0 folder below the bin and place the Log4net.dll version 1.2.10.0 into the folder, which can be renamed to Log4net1.2.10.0.dll.

2. config add

  <Runtime>    <assemblybindingxmlns= "Urn:schemas-microsoft-com:asm.v1">      <dependentassembly>        <assemblyidentityname= "Log4net"PublicKeyToken= "1b44e1d426115821" />        <CodeBaseversion= "1.2.10.0"href= "Bin/log4net1.2.10.0/log4net1.2.10.0.dll" />      </dependentassembly>      <dependentassembly>        <assemblyidentityname= "Log4net"PublicKeyToken= "669E0DDF0BB1AA2A"Culture= "neutral" />        <BindingRedirectoldversion= "0.0.0.0-2.0.8.0"newversion= "2.0.8.0" />      </dependentassembly>    </assemblybinding>  </Runtime>

3. The results are as follows

Experience:

1, the file needs to be placed under the bin, and set up a separate folder, note: If you do not set up a folder, directly rename the Log4net1.2.10.0.dll thrown into the bin will be an error, it should be the detection method is based on the name of the search.

2, ClassLibrary class library in a separate compile time, will be replaced by the high version of the lower version, it will be possible to error, you can create the DLL in the development of the DLLs are not copied to the bin, the setting is under the reference DLL right-click, Copy Local set to False, the operation is as follows:

3, in order to be able to upload log4net1.2.10.0.dll to Gitlab above, you can create a corresponding folder in WebApp, and set the copy to the output directory-always copy , vs compile will automatically log4net1.2.10.0/ Log4net1.2.10.0.dll Copy to Bin below

Summarize

Hopefully, this article will help more people resolve version compatibility issues with NET components.

Reference articles

Https://www.cnblogs.com/shijun/p/3713830.html

6183353

Https://docs.microsoft.com/zh-cn/previous-versions/dotnet/netframework-3.5/6bs4szyc (v%3dvs.90)

HTTPS://DOCS.MICROSOFT.COM/ZH-CN/PREVIOUS-VERSIONS/VISUALSTUDIO/VISUAL-STUDIO-2008/YX7XEZCF (v=vs.90)

The article and the opinion, may because the knowledge and the experience reason, the analysis one-sided, please many understanding.

Net DLL component version compatibility issues