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?

"Note that my DLL is registered in Windows using a machine.config file" - do you mean your DLL is being put in the GAC, but System.ValueTuple.dll isn't? I can see how that would cause problems. — Jon Skeet, Mar 17 '17 at 21:35
@JonSkeet Yes. But I was under the assumption that Windows will look for referenced DLLs in the same folder as the calling application, which in this case is my DLL. — Mike Lowery, Mar 17 '17 at 21:37
The path of the DLL never plays a role to find assemblies, only the startup EXE. — Hans Passant, Mar 17 '17 at 21:44
ValueTuple is built into .NET Framework 4.7, which was just announced and will be released shortly. That said, I don't understand why you ran into a problem with 4.6.2, since you imported the ValueTuple package from nuget. I'm not an expert at assembly binding, but your solution (below) worries me. Feel free to file an issue on the rolsyn repo with a small repro project (zipped). — Julien Couvreur, Apr 08 '17 at 21:39
I ran into the same problem after updating (seemingly un-related) Nuget packages. Upgrading to 4.7.2 resolved the issue, but I also had to remove binding references. — sbkrogers, Jan 20 '19 at 19:18
It is funny but I faced same problem again after downgrade `System.ValueTuple` assambly and just comment out `System.ValueTuple` dependentAssembly section under `runtime > assemblyBinding` in web.config file. and now it is working. — Hardik, Mar 21 '19 at 07:38

score 91 · Answer 1 · answered Nov 28 '18 at 05:09

91

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.

answered Nov 28 '18 at 05:09

Robin Vessey

4,329
1
23
21

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. – stuzor Jan 02 '19 at 05:42
1

IMO, this is the only change you need in order to get it work. – Ali Khakpouri Sep 09 '19 at 16:27
It works for me, likely that the machine already have it, by take out that runtime stuff from web.config helps. Thanks for this. – Osify Jan 29 '20 at 02:47
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. – Jesse Sierks Mar 29 '20 at 14:20
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. – Andrey Burykin Jul 08 '20 at 10:04
1

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. – nikita Aug 31 '20 at 12:22

score 62 · Answer 2 · answered Jun 01 '18 at 06:01

62

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.

answered Jun 01 '18 at 06:01

Djensen

1,337
1
22
32

2

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. – Matt Williams Jun 21 '18 at 07:11
2

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! – eddiewould Oct 27 '18 at 22:46
Exactly what my issue was, had a library using the NuGET and the unit tests using what I had locally, installing the NuGET onto the unit test project resolved the issue. – HenryMigo Sep 28 '22 at 12:53

score 23 · Answer 3 · answered May 29 '19 at 09:51

23

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

answered May 29 '19 at 09:51

Ogglas

62,132
37
328
418

3

Found a random server that only had 4.6 installed. This answer should be the starting point before all the others. – Jordan Parker Jan 25 '21 at 20:42

score 16 · Answer 4 · answered Sep 24 '20 at 14:08

16

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.

answered Sep 24 '20 at 14:08

watsonST

211
3
4

Happened for me as well and the only way was to comment out the binding redirect. However not sure why that fixes it because the version is correct. – Lenard Bartha Jan 11 '23 at 23:57

score 11 · Answer 5 · answered Jan 11 '18 at 21:32

11

FWIW, I had this issue on my testing project using Moq. Someone had set the project to .NET 4.7, but I was on 4.6.2. Not wanting to move to 4.7 yet, the solution was to downgrade the version to Moq 4.7.145. The System.ValueTuple v 4.3.1 worked together with it.

answered Jan 11 '18 at 21:32

malckier

1,052
2
14
22

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. – IbrarMumtaz Feb 13 '18 at 13:29

score 9 · Accepted Answer · answered Mar 18 '17 at 19:53

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>

This got me close but for nuget version 4.5 I had to use the following in my windows service config — Pete, Sep 07 '18 at 14:27

score 8 · Answer 7 · answered May 17 '17 at 08:50

I faced the same exception when there was a nuget package version mismatch. (In the DLL was 4.3.1 used while in the main program 4.3.0.) I have resolved the issue by upgrading the packages to the same version... Checking and unifying the package versions could hopefully help you as well.

score 3 · Answer 8 · answered Jul 18 '19 at 14:22

3

I hade the same issue, i solve the probleme by changing the target framwork of the project to .Net Framwork 4.7.1.

System.ValueTuple now supports .NET Framework 4.7

answered Jul 18 '19 at 14:22

Hamza Elm

166
1
7

score 3 · Answer 9 · answered Jan 09 '20 at 11:30

In my solution I found 2 different trouble maker. Either in the App.config or Web.config file:

Version mismatch: The version installed via NuGet did not match the version in the config file. Solution: Change the version manually in the .config file.
Duplicate entries: I found duplicate entries for ValueTuple. In my case one for 4.0.3.0 and another one for 4.5.0. Removing the older entry solved the issue.

In another case I managed to fix the issue by removing unneeded references and getting rid of the ValueTuple NuGet package altogether.

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. — steve, Apr 21 '21 at 13:37

score 1 · Answer 10 · answered Apr 28 '19 at 09:13

1

My issue was that I was developing against 4.6.1, but releasing on 4.7.2. Luckily I don't mind which .Net framework this project was built for, so I installed 4.7.2 on my developer instance, then upgraded all the Nuget packages.

(Using SQLite on AWS EC2)

answered Apr 28 '19 at 09:13

Richard Whitehouse

679
3
14
28

score 1 · Answer 11 · answered Jun 18 '20 at 06:17

In my case I think something delete this dll from project and framework folders, maybe during installing something it flied; so my project during debugging couldn't find that dll and throw that error. I installed

Install-Package System.ValueTuple -Version 4.5.0

Package and than everything worked again. Before doing further complicated solutions as described above answers may installing ValueTuple package works for you.

score 1 · Answer 12 · answered Jul 16 '20 at 12:35

If you have AutoMapper version 8.0 or lower referenced in any of your projects, it's possibly the source of the issue. See this github issue for more information.

If I understand correctly, the issue is that .NET Framework versions below version 4.7 did not have System.ValueTuple shipped with them by default, so AutoMapper was using a NuGet package reference for the assembly since it has build targets for Framework versions below 4.7. This caused some funky Microsoft stuff.

The easiest solution is to upgrade your AutoMapper references to version 8.1.0 or newer, where they have scraped all uses of the assembly from their codebase and removed the dependency.

The _source_ is the framework itself, we're all victims :) – Lucian Bargaoanu Jul 16 '20 at 12:41 — Lucian Bargaoanu, Jul 16 '20 at 12:41

score 1 · Answer 13 · answered Nov 03 '20 at 00:16

I experienced the same error "Could not load file or assembly System.ValueTuple.dll..." on my Windows Server 2016. However, the site worked fine on my dev machine.

My solution was simple, I grabbed this dll from my dev machine and dropped it in the site's "bin" folder on the server. It worked.

score 1 · Answer 14 · answered Mar 19 '21 at 10:02

I hope this isn't thread necromancy, because this is still the #1 searched thing on Google. None of the other comments worked for me sadly.

We resolved this issue recently after over a year with this problem. The issue was a package called 'GitVersion'. So for anybody who is still struggling with this and looking around the forums I know quite a few are; I would advise you check your packages and see what their dependencies are.

score 1 · Answer 15 · answered Dec 16 '21 at 14:54

1

Fixed this by switching the Copy Local flag on my reference to System.ValueTuple from copy always to none. (It was on an assembly containing tests).

answered Dec 16 '21 at 14:54

flobadob

2,804
2
22
23

score 1 · Answer 16 · answered Mar 25 '22 at 10:45

1

Right clicking References and choosing "Migrate packages.config to PackageReference..." solved the problem for me (and other similar issues).

answered Mar 25 '22 at 10:45

Xack

111
1
5

score 0 · Answer 17 · answered Feb 25 '19 at 16:33

0

I had this same issue with an AutoMapper 8.0.0.0 dependency on version 4.5 after upgrading from .NET 4.5.1 to 4.6.1. Reinstalling the automapper nuget package worked for me.

answered Feb 25 '19 at 16:33

Brian Swart

922
1
9
25

I had to downgrade AutoMapper to 6.2.2 to get it working. – Jacob Apr 17 '19 at 13:40

score 0 · Answer 18 · answered Aug 16 '19 at 18:39

0

IF your are unable to update .Net Framework to the latest version, then downgrade Package: Microsoft.Net.Compilers to the version up to 2.10. This solved the issue in my case.

answered Aug 16 '19 at 18:39

Anwar

1

This seems to be a potential answer to a question, but not the question which was asked here. – Wai Ha Lee Aug 16 '23 at 09:55

score 0 · Answer 19 · answered Oct 28 '19 at 17:17

I had a library which used a newer version of the System.ValueTuple NuGet package. I then used another library which caused me to use the older version installed in the main project for the first time. That caused this exception to reveal itself. Updating both (or, converging them in any way - downgrading both is fine too) - fixed the issue.

score 0 · Answer 20 · answered Jun 13 '20 at 18:36

0

I resolved this issue by installing System.ValueTuple from nuget. It was not previously installed but I guess RestSharp or another library is using it.

So this got it fixed.

answered Jun 13 '20 at 18:36

Olorunfemi Davis

1,001
10
23

score 0 · Answer 21 · answered Nov 26 '20 at 12:53

0

Solved it by installing VS 2019.

answered Nov 26 '20 at 12:53

user1602496

31
1
5

score 0 · Answer 22 · answered Sep 28 '22 at 13:15

I had this issue in a Visual Studio setup/installer project. For some reason my project had multiple instances of System.ValueTuple.dll:

Deleting the extras at the bottom made the setup project build. For one of them I had to right click, choose "Find In Editor", and delete from the resulting window. Otherwise I got a cryptic error (something to the effect of "the parameter is incorrect" if I recall correctly).

Could not load file or assembly 'System.ValueTuple'

22 Answers22

Linked

Related