Could not load file or assembly 'System.ValueTuple'

Question

I've got a VS2017 project that compiles to a DLL which is then called by an EXE written by someone else. Both projects target .Net Framework 4.6.2. I rewrote one of my DLL methods to return a tuple and also imported the associated NuGet package. When I compile the project it includes System.ValueTuple.dll in the output directory which is then deployed to other machines where my DLL is loaded and called by the EXE. But when the EXE attempts to call the method that returns a tuple it crashes:

Unexpected Error Could not load file or assembly 'System.ValueTuple, Version=4.0.1.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.

I'm not understanding why it's not finding the file since it's in the same folder as my DLL. Apparently MS did not include this assembly in .Net Framework 4.6.2.

Note that my DLL is registered in Windows using a machine.config file. I'm guessing that if I also add System.ValueTuple.dll to this file it will work (haven't tried yet and not sure this is the best approach, especially long term.) Is there a better way, besides waiting for 4.6.3 and hoping it includes this assembly?

Solution 1

I resolved this issue by registering System.ValueTuple in my computer's machine.config file (along with my own DLL which was already registered there). I don't particularly like this approach though since it's dependent upon the DLL version which is subject to change at any time. Hopefully MS will just add this assembly to the next version of the .Net Framework.

<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
  <dependentAssembly>
    <assemblyIdentity name="System.ValueTuple" publicKeyToken="cc7b13ffcd2ddd51" />
    <bindingRedirect oldVersion="0.0.0.0-99.99.99.99" newVersion="4.0.1.0" />
    <codeBase version="4.0.1.0" href="e:\exec\System.ValueTuple.dll" />
  </dependentAssembly>
  ...
</assemblyBinding>
</runtime>

Solution 2

ok this feels completely wrong but I cut

  <dependentAssembly>
    <assemblyIdentity name="System.ValueTuple" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.0.3.0" newVersion="4.0.3.0" />
  </dependentAssembly>

This out of my web.config for the main application.

I was really just seeing what happened to see if there was an underlying dependency or something, not expecting it to run. It just carried on working, all the new functions I have added in the last few days still work.

Solution 3

I just had this issue myself. Not on Localhost while developing, but only on production server. In the end it turned out to be some sort of conflict between .Net Framework 4.6.1 and me having System.ValueTuple installed from Nuget in version 4.5.0.

The solution turned out to be, to downgrade the System.ValueTuple Nuget package to 4.3.0. Then it worked, like nothing had ever been an issue.

I suspect that this only happened on production server, cause of a different version of .net framework installed.

Solution 4

Solved it by installing .NET Framework 4.7.2 Runtime on the machine the error occurred on. Simple and no need to add bindingRedirect or downgrading NuGet packages.

https://dotnet.microsoft.com/download/dotnet-framework/net472

Solution 5

Adding on to Robin's answer for just changing the Web.config. I was able to get away with only commenting out the binding redirect tag.

<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>

This got rid of the error for me.

View more solutions

Comments

[Mike Lowery]

System.ValueTuple has been added to .Net Framework 4.7.

[IbrarMumtaz]

Moq 4.7.145 does not depend on ValueTuple that's why the downgrade works. No idea why the latest version of Moq is causing this issue. This is how i landed here.

[Matt Williams]

This worked for me. I'm using System.ValueTuple in a .NET Standard 2.0 project and was having trouble running it from .NET Core 2.0 until I downgraded to 4.3.0.

[Pete]

This got me close but for nuget version 4.5 I had to use the following in my windows service config <dependentAssembly> <assemblyIdentity name="System.ValueTuple" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-4.0.3.0" newVersion="4.0.3.0" /> </dependentAssembly>

[eddiewould]

Worked for me too - I had a class library targeting .NET Standard 1.3 which was consumed by a AspNetCore project targeting 2.0. Downgrading to 4.3.0 fixed the issue - thanks!

[stuzor]

This worked for me. Djensen's solution below was also necessary, because initially I had multiple projects with different nuget versions. I suspect what happened is that, when it first built, it noticed the mismatch and so added the bindingRedirect in the app.config. So even after fixing the nuget references in all projects to be the same, this bindingRedirect still lingered.

[Jacob]

I had to downgrade AutoMapper to 6.2.2 to get it working.

[Ali Khakpouri]

IMO, this is the only change you need in order to get it work.

[Osify]

It works for me, likely that the machine already have it, by take out that runtime stuff from web.config helps. Thanks for this.

[Jesse Sierks]

This worked for me, too. I'm not sure how/when this entry was added, but my version of the DLL was outside the range.

[Andrey Burykin]

As far as I see current version of the System.ValueTuple assembly in the .Net Framework is 4.06.26515.6 but the latest version in the nuget package is 4.0.3.0. It means if developer wants to use the nuget package System.ValueTuple then it's required to forcibly set binding redirect from 0.0.0.0-4.99.99.99 to 4.0.3.0.

[Lucian Bargaoanu]

The source is the framework itself, we're all victims :)

[nikita]

There are three versions in assemblies - only AssemblyVersion really matters . You are talking about AssemblyInformationalVersion (4.06.26515.6) which is irrelevant and for information purposes only.

[Jordan Parker]

Found a random server that only had 4.6 installed. This answer should be the starting point before all the others.

[steve]

When you say duplicate entries: do you mean different versions in different projects? I had that and setting them all to the same version fixed this issue for me.

[David Shepard]

This is the only advice that helped me!