CODEWITHSUNDEEP
c#.netdll
Alwyn
Alwyn

Reputation: 8337

How to resolve .NET Dll Hell?

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.

Upvotes: 12

Views: 7142

Answers (4)

Alwyn
Alwyn

Reputation: 8337

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.

Upvotes: 1

Adrian Godong
Adrian Godong

Reputation: 8921

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.

Upvotes: 4

Mike Zboray
Mike Zboray

Reputation: 40838

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.

Upvotes: 2

Sam Axe
Sam Axe

Reputation: 33738

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>

Upvotes: 3

Related Questions