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