Incompatible .NET Standard assemblies that should have been compatible?

NoOne picture NoOne · Jun 9, 2018 · Viewed 9.5k times · Source

I have a .NET Standard 2.0 DLL project.

Project target framework

It has no other references, apart from NETStandard.Library 2.0.1 and all is fine.

It is referenced by a WPF application and everything seems to work fine.

Once I add a nuget package for System.Collections.Immutable 1.5.0 to the DLL project, a yellow exclamation mark appears on the Dependencies root of the Solution Explorer. (Hm... I now see that the exclamation remains even after I remove this package, but I guess this is a VS bug since everything seemed to work just fine before adding this library)

exclamation without explanation...

Having both packages, everything builds fine, but when I try to use the ImmutableDictionary, I get this:

System.IO.FileNotFoundException: 'Could not load file or assembly 'System.Collections.Immutable, Version=1.2.3.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.'

Looking at the nuget packages, I understand that those two should work together, since (from my understanding) the 'System.Collections.Immutable` library says it supports .NET standard 2.0.

packages

I am very new to the .NET Standard world.

Looking at the public key token of the System.Collections.Immutable.dll in my main app's bin folder I see that it was indeed b03f5f7f11d50a3a as expected. However the version is different.

Hm...

Normally, in the old .NET I would try to add an assembly redirection in the app's config file. But doing this here does not seem to make any difference. Adding this into my WPF app that references the DLL:

  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Collections.Immutable" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.0.11.0" newVersion="4.0.11.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>

... changes the exception to this:

System.IO.FileNotFoundException: 'Could not load file or assembly 'System.Collections.Immutable, Version=4.0.11.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.'

Inner Exception

FileNotFoundException: Could not load file or assembly 'System.Collections.Immutable, Version=1.2.3.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

What is going on here? Can't I use those two nuget packages together?

UPDATE:

I now notice that the DLL version that I got was from System.Collections.Concurrent.dll, while I am interested at System.Collections.Immutable.dll which is nowhere to be found on my bin folders... I haven't even found where the nuget packages are stored in my solution.

UPDATE 2:

It turns out that I get the exact same behavior when I create a new solution with similar setup (Full framework console app referencing .NET Standard 2 DLL).

Following @Lasse Vågsæther Karlsen's advice, I have downloaded the nuget package from here https://www.nuget.org/packages/System.Collections.Immutable, extracted the correct DLL out of it, and placed it in my bin folder. Then the console app worked.

I am using the 15.7.1 version of Visual Studio. I am not sure what are the changes are of this being fixed in the latest 15.7.2 version...

You can try my verifiable example by downloading it from here: https://mega.nz/#!YZMwGABD!eHHxvNdO59l2m5ZlHMG1vvqCd-GHv3EVckR-9htDojs

Answer

Alex Ghiondea - MSFT picture Alex Ghiondea - MSFT · Jun 19, 2018

There are 2 ways to fix this:

1 - Update the project file for the ConsoleApp1 to include this in the property group

<RestoreProjectStyle>PackageReference</RestoreProjectStyle>

2 - Add a reference to System.Collections.Immutable directly in the ConsoleApp1 project.

This is a known issue where using Project-to-Project references and NuGet package references does not automatically flow the references correctly. This is being tracked here but one of these workarounds should unblock this.