27

I tried to update my project to .NET Standard 2.0 and during testing I got catch an exception:

System.IO.FileLoadException: 'Could not load file or assembly "System.ValueTuple, Version=0.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" or one of its dependencies. The definition of the assembly manifest found does not match the reference to the assembly.

This is assambly exists in package.config and exists on the package's folder. I tried some versions of System.ValueTuple package, result is one.

Why the version of dependencies «0.0.0.0»?

Does anyone have an idea about the problem?

VS 2017 Preview, UnitTestApp, .NET Framework 4.7.

In the unit test app I create EF model (Microsoft.EntityFrameworkCore, Microsoft.EntityFrameworkCore.SqlServer 2.0.0-preview2-final, it needs in .NET Standard app). The Unit test method - insert into table some rows using EF db model, and call 'savechanges', after that throw this exception.

When I used EntityFrameworkCore 1.1.2 (dll with EF model - Standard 1.4, unit test Framework 4.6.2) - this test worked well.

iehrlich
  • 3,572
  • 4
  • 34
  • 43
DmitrySpb
  • 381
  • 1
  • 4
  • 7
  • I have a similar problem with VS15.3.2 using a netstandard2.0 project + a 4.6.1 project. Using a ValueTuple function at runtime throws the exception. I even switched from 4.6.1 to 4.7 to no avail. netstandard2.0 depends on the NETStandard.Library-2.0 which in turn only depends on Microsoft.NETCore.Platforms >= 1.1.0. The Microsoft.NETCore.Platforms doesn't show any dependencies, but i think this package is somehow corrupted. – Henk Aug 23 '17 at 07:53
  • I also tend to this. I think NETStandard 2.0 is still raw. You need to wait a bit for using NETStandard 2.0. – DmitrySpb Aug 24 '17 at 10:10
  • I installed System.ValueTuple by nuget manager and fixed my problem – Amirhossein Yari Mar 07 '20 at 15:09

5 Answers5

25

I solved this problem by enabling Automatic Binding Redirection in my .NET Framework 4.7 project (that references .NET Standard 2.0 library). Binding redirection can be enabled by manually editing project's .csproj file and addind following snippet a child of Project element:

<PropertyGroup>
  <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
  <GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
</PropertyGroup>

Visual Studio then during build generates neccessary assembly redirections to project's app.config, similar to this:

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
  <dependentAssembly>
    <assemblyIdentity name="System.ValueTuple" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.0.2.0" newVersion="4.0.2.0" />
  </dependentAssembly>
</assemblyBinding>

allowing correct assembly to be loaded.

Ňuf
  • 6,027
  • 2
  • 23
  • 26
1

Using the #23 answer, I modified web.config and add: (under the main root configuration:

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

Guillermo

elGuille.info
  • 11
  • 3
0

I've been wrestling with something similar - dll's in the bin folder of webapi2 sln after build. I've deleted a list of dll's and refreshed each time - the error moves on to a different dll. Finally, after deleting 8 dll's the site fires up correctly. My next step is to write a post-build script to delete these dll's from the bin folder. A bit of a hack but the elegant solution can come later.

badcop666
  • 121
  • 2
  • 9
  • The app still runs without the referenced DLLs? I am a little confused as to how that works. To be safe, I would do this and then navigate to a page where you KNOW that one of the referenced DLLs is used to verify that all is okay. – Cityonhill93 Nov 13 '17 at 19:38
  • To be clear - the dll's I removed from the bin output folder(s) were in the GAC. They loaded correctly from the GAC but failed to load when they are found in the bin folder. So the dll loader starts to look in the bin folder even though loading from the bin folder will fail. All seems strange - or, conversely, a normal day in .NET land :-) – badcop666 Nov 14 '17 at 20:48
0

in my case after update dotnet framework from 4.6 to 4.7 problem solved

Ali Sadri
  • 1,570
  • 14
  • 15
0

I had the same problem, only when I ran the console application on a server. Eventually I deleted all files from that directory on the server and uploaded again. Then it worked. Probably an old dll file which was uploaded in the past.

Gregory Liénard
  • 1,071
  • 3
  • 7