runtime: (Packaging issue in System.IO.FileSystem) System.IO.File in .NET Standard library fails when run in unit test

From @davkean on January 20, 2017 3:49

From @gulbanana on December 16, 2016 11:28

Possibly this issue should be in a vstest repository but I can’t find one. Repro: https://github.com/gulbanana/repro-netstandard-systemio

When using System.IO in a .NET Standard 1.4 class library, unit tests referencing the library fail. The error is Message: System.IO.FileLoadException : Could not load file or assembly 'System.IO.FileSystem, Version=4.0.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Copied from original issue: dotnet/roslyn-project-system#975

Copied from original issue: Microsoft/vstest#363

About this issue

Original URL
State: closed
Created 7 years ago
Comments: 28 (9 by maintainers)

Commits related to this issue

Build cecil in desktop configuration for net46 target The linker depends on cecil, shipping with a netstandard1.3 build of Mono.Cecil. Some of the reference assemblies for netstandard1.3 have lower v... — committed to sbomer/linker by sbomer 7 years ago
Build cecil in desktop configuration for net46 target The linker depends on cecil, shipping with a netstandard1.3 build of Mono.Cecil. Some of the reference assemblies for netstandard1.3 have lower v... — committed to dotnet/linker by sbomer 7 years ago

Most upvoted comments

Here’s an example of the binding redirects I had to write recently to use Roslyn 2.0.0 in an old-msbuild test project.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.IO.FileSystem" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.0.2.0" newVersion="4.0.2.0" />
      </dependentAssembly>
    </assemblyBinding>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Collections.Immutable" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-1.2.1.0" newVersion="1.2.1.0" />
      </dependentAssembly>
    </assemblyBinding>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Security.Cryptography.Algorithms" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.1.0.0" newVersion="4.1.0.0" />
      </dependentAssembly>
    </assemblyBinding>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Security.Cryptography.Primitives" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.1.0.0" newVersion="4.0.1.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

gulbanana on Apr 3, 2017

Binding redirects being generated only for executables should be considered a Pri 1 bug.

bradwilson on Aug 28, 2017

I found out what versions to use by examining the contents of the bin/Debug folder and opening the DLLs with ilspy to discover their AssemblyVersion. I don’t think this issue should be closed - it’s a terrible UX and it will never be realistic to expect all .net hosts and tools to work around it.

gulbanana on Apr 3, 2017

I experienced this with my xunit project not generating binding redirects. You also have make sure you have this:

 <OutputType>Exe</OutputType>

As binding redirects are only generated for executables not libraries.

dazinator on Jul 26, 2017

I’ve solve this adding

<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>

in .csproj file. Ref: https://msdn.microsoft.com/en-us/library/2fc472t2.aspx

zahasoftware on May 29, 2017

I had a similar issue with “System.Runtime.Serialization.Primitives”. I have the same structure, a .netstandard 1.4 library and a net461 UnitTest project. Adding System.Runtime.Serialization.Primitives nuget package (Version 4.1.1) to the UnitTest project works as a workaround.

Portikus on Mar 17, 2017