Incompatible .NET Standard assemblies that should have been compatible?

Question

I have a .NET Standard 2.0 DLL project.

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)

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.

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.

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

Caducity

Out of interest, are you able to reproduce this using a simple console app (targeting the full framework) rather than WPF? If so, please could you post a minimal reproducible example? That would make it easier to help you. – Filippa

@JonSkeet OK. I am on it. I have added an update to my question too. I had missed a small detail regarding the DLL names. – Caducity

If the file isn't found then it isn't the assemblies that are incompatible, but it may appear that the nuget system trips up. If you find a copy of the missing dll and place it in the binary folder, does it run then? – Demurrage

Nitpick: 15.7.3 is the latest Visual Studio 2017 version. – Tedtedd

@JonSkeet I have added a verifiable example solution download link. But it turns out that Lasse Vågsæther Karlsen was right and something is not right, either with the Nuget system or with that nuget package or with my VS. – Caducity

If someone knows where VS stores the nuget packages, I would be grateful to know. There might be a chance of it downloading a corrupt Nuget package (due to network error?) and then giving me problems on all solutions? I don't seem to find where my Nuget packages folder is (at least it doesn't seem to be inside my solution folder)... Has this been moved to a more central location? Can you reproduce the problem on your VS? – Caducity

Microsoft still has to sort out some DLL Hell issues with .netstandard, it is work-in-progress. I think the core problem is that this assembly is also stored in the GAC. But it is the wrong version to keep a .netstandard project happy, version 1.1.37.0 on my machine. It should copy the assembly, but doesn't. Not so sure that it could. I think the most reasonable workaround is to also add the nuget package to your WPF project, that does solve the problem. – We

question did you add the nuget package to both the .net standard class library and wpf project? – Crisscross

@KenTucker Yes, I did, as Hans Passant said above, and it fixes the problem. – Caducity

There are a lot of Github issues that talk about this problem. This was supposed to get fixed in VS2017, but that didn't happen and it got pushed back to a milestone named "Unknown". This one might be best, it offers another approach. – We

Answer 1

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.

Cumquat

It's worth noting this comment though: github.com/Microsoft/msbuild/issues/1582#issuecomment-278937269 . Maybe, another better (?) fix is this: <PackageReference Update="PlaceholderToConvinceThisProjectToGetTransitivePackageReferenceFromProjectReferences"/> – Caducity

Answer 2

For my case, it turn out to be projects in the same solution have different versions of System.Collections.Immutable.dll. (1.4.0 and 1.5.0)

Some how MSBuild does not notice that there are 2 versions of the dll and trying to find and load dll version 1.5.0 instead of 1.4.0 in some project.

To solve this just update and make sure that every proj. in the same sln has the same version of the dll.

I face this problem with System.Net.Http also.

Banderilla