How to resolve .NET Dll Hell?

Question

How to fix?

I have 2 3rd party assemblies, that uses NewtonSoftJson.dll. The catch is one of them uses the older 3.x.x and another using 4.5.x. So at run time at least 1 of the 2 assemblies complains about the other.

How can I resolve this? I could set up services, but the codes and environments aren't currently set up that way. It's also too much refactoring than can be done safely in the given amount of time.

This may help: http://blogs.msdn.com/b/abhinaba/archive/2005/11/30/498278.aspx — Oded, Feb 06 '13 at 22:21
http://stackoverflow.com/questions/3158928/referencing-2-differents-versions-of-log4net-in-the-same-solution — Oded, Feb 06 '13 at 22:22
This is _not_ for Silverlight right? Because if it is, you may be in trouble: http://stackoverflow.com/questions/9947747/resolving-using-multiple-assembly-versions-from-3rd-party-dependencies — Chris Sinclair, Feb 06 '13 at 22:33

score 4 · Accepted Answer · answered Feb 06 '13 at 22:21

4

I happened to have the exact problem with Newtonsoft and another third party library. The issue with Newtonsoft v3.x and v4.x is that the newer library now comes with a public key token. This made the assembly redirection solution useless; but it is a perfectly valid solution for most other cases.

I ended up reimplementing the third party library myself. If you have access to the source code of the third party library, you can always rebuild the library using the newer Newtonsoft DLL. You may need to make minor changes if any of the method signature changed.

answered Feb 06 '13 at 22:21

Adrian Godong

8,802
8
40
62

1

Run into the same problem, download a LITTLE app (just a couple of Kbs) and need a framework version I don't have. To install it, you have to search it yourself that can be lead into frustration (version hell). It is a LITTLE app but needs allot of bullshit around it. After installing the framework it needs updates (look like endless updates). This is not very userfriendly and insane way to deploy an app. Now I understand why Windows is that huge and now I know why there are so many bold hairless men in the world. Think twice to use .NET for your products. – Codebeat May 24 '14 at 13:25

score 3 · Answer 2 · answered Feb 06 '13 at 22:16

The Microsoft article "Redirecting Assembly Versions" has this to say:

The following example shows how to redirect one version of myAssembly to another, and turn off publisher policy for mySecondAssembly.

<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="myAssembly"
          publicKeyToken="32ab4ba45e0a69a1"
          culture="en-us" />
        <!-- Assembly versions can be redirected in application, 
          publisher policy, or machine configuration files. -->
        <bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
      <assemblyIdentity name="mySecondAssembly"
        publicKeyToken="32ab4ba45e0a69a1"
        culture="en-us" />
        <!-- Publisher policy can be set only in the application 
          configuration file. -->
        <publisherPolicy apply="no" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

Can you show how to do this so each assembly that has a dependency on a different version of `NewtonSoftJson` gets the correct version? — Oded, Feb 06 '13 at 22:17
@Oded: I can not. I have not got the time right now to explore this. Perhaps this weekend. — Sam Axe, Feb 06 '13 at 22:25

score 2 · Answer 3 · answered Feb 06 '13 at 22:17

Typically, you resolve this through configuration in your app/web config. You can use the probing element to specify a private path and put the two versions in separate folders:

<configuration>
   <runtime>
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
         <probing privatePath="bin;bin2\subbin;bin3"/>
      </assemblyBinding>
   </runtime>
</configuration>

The other way is to use assembly binding redirection. But that will only work if you know that the versions are compatible. Since you are not using them directly I'm not sure you know that and the publisher has indicated some incompatibility by changing the assembly version.

Alwyn · Answer 4 · 2013-07-12T17:24:08.050

1

Ended up using decompiler, add project to solution, reference the new dlls, fix bugs, and recompile, point to the recently added project.

I couldn't use the assembly redirect since the public key token has changed. Apparently a different key was used to compile 1 of the referenced assemblies. Had to resort to the more drastic measures.

edited Jul 12 '13 at 17:24

answered Feb 06 '13 at 23:44

Alwyn

8,079
12
59
107

How to resolve .NET Dll Hell?

4 Answers4