Using two versions of a DLL in a .net Core application

Question

I have a C# .NET Core project that references a C# .NET Framework 4.6.2 project.

Both projects have a dependency on IdentityModel.dll, not directly, but via components.

The .NET Core project's dependency is on IdentityModel.dll version 4.4.0. The .NET Framework project's dependency is on IdentityModel.dll version 3.10.10. The constructors for some of the classes in the two libraries do not match, so it is not possible to downgrade the .NET Core project's dependency or upgrade the .NET Framework project's dependency.

Obviously, this creates a problem. Only one IdentityModel.dll ends up in the bin output folder. It happens to be the calling project's dll, ie, the .NET Core project's, which is 4.4.0. That causes code that relies on the .NET Framework project's code to fail at runtime.

In an attempt to fix this problem I added the following to the .NET Core project's.csproj file:

<ItemGroup>
  <Content Include="..\lib\IdentityModel.3.10.10\IdentityModel.dll">
    <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    <Link>IdentityModel.3.10.10\IdentityModel.dll</Link>
  </Content>
</ItemGroup>

That has the effect of looking for the IdentityModel 3.10.10 dll in the solution's /lib/ folder and outputting it into an IdentityModel.3.10.10 folder in the bin output folder. Clearly this is desirable. It gives me a second copy of IdentityModel.dll in a separate folder.

All that is needed now is to let the referenced .NET Framework project know that when it needs IdentityModel.dll it needs to look in the correct folder.

I attempted doing this by adding a binding redirect to the .NET Framework project, by changing its app.config as follows:

<dependentAssembly>
  <assemblyIdentity name="IdentityModel" culture="neutral" publicKeyToken="e7877f4675df049f"/>
  <bindingRedirect oldVersion="3.0.0.0-4.4.0.0" newVersion="3.10.10.0" />
  <codeBase version="3.10.10.0" href="IdentityModel.3.10.10\IdentityModel.dll" />
</dependentAssembly>

I can't say that I was very surprised when that didn't work, because it is probably the owner assembly, the .NET Core project, that needs to know where to find the 3.10.10 version of the dll.

So, after some googling I added the following to the .NET Core project's.csproj file:

<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>

From what I understand, binding redirects are no longer a thing in .NET Core, but the above line is supposed to magically resolve dependencies. But it doesn't.

The IdentityModel.dll that gets called is still the one on the bin folder, which is the 4.4.0 version.

I have also looked in the .NET Core project's deps.json file and there are no references to the 3.10.10 version of the dll.

How can I let the .NET Core project know that when the .NET Framework assembly needs the 3.10.10 dll to look in the folder where it has been placed during the build?

Answer 1

Core and Framework are largely incompatible. It does look like IdentityModel is available in.Net Standard 2.0 which is compatible with.Net Framework 4.6.2+ and Core 2.0+. However, if you are using NuGet and the dependency is multi-targeted, it will attempt to find a 'best match' which usually means it will prefer the Framework version on Framework projects. To overcome this you will have to download the dependency and add it manually as a reference to the specific assembly. You can also extract the correct version from the NuGet package itself, which is just a fancy zip file with a different extension.

As far as referencing two versions, that also can be done by manually adding references, but this is a situation I would personally recommend avoiding when possible as maintenance will become difficult.

If at all possible, your best option is to migrate off of Framework as soon as possible, though I understand this isn't as easy as it sounds.