System.IO.FileNotFoundException thrown when referencing same DLL name with 2 different assembly versions within a single application

[rjmille2]

We have a console based c# application that we are using Moq for unit testing. The application has a reference to Nuget package A and Nuget package B. Nuget package A then has another nuget reference to Nuget Package C version 1.0.0 and Nuget package B has a reference to Nuget Package C version 2.0.0. When we try to run our unit test, when it tries to load Nuget package A, a System.IO.FileNotFoundException is thrown when trying to load the .dll with version 1.0.0 because version 2.0.0 has already been loaded into the process. All of these nuget packages are internally created and are not signed, so there is no publickeytoken to use in an assembly binding redirect in the app.config file. The application that is produced runs just fine at runtime, but the unit tests fail with the FileNotFoundException. I think this is probably more of a Castle issue, but maybe you can help us get this redirected to the correct place within their repository or know of some sort of workaround in Moq.

[stakx]

Sorry, this appears to have nothing at all to do with Moq nor with Castle DynamicProxy. This is simply about NuGet's version resolution algorithm and the runtime's assembly version binding policies. Referencing two different major versions of the same package is bound to provoke problems, as a difference in the major version usually signals some kind of incompatibility / breaking changes.

You can force a specific version of C by referencing it directly from your console app. If you're running on .NET Core which has a more lenient version binding policy, you might get this to run more easily than on the .NET Framework, which is rather strict about version mismatches. There is some official NuGet documentation that describes how NuGet versions are resolved... Perhaps you'd find a hint in there what to do in such a situation. (I'll add a link here if I can find it again.) The most likely course of action seems to upgrade or downgrade either A or B until they agree on C's major version.

Until we've got proof that this is an issue caused by Moq or DynamicProxy (which seems unlikely) I'm going to close this.

[rjmille2]

This is not a nuget versioning problem. If I have time sometime, I'll try to create an actual code repository somewhere that reproduces the problem so that you can see the issue.

[stakx]

This is not a nuget versioning problem.

But it may still be a plain assembly version binding issue, like I said:

This is simply about NuGet's version resolution algorithm and the runtime's assembly version binding policies.

Please make sure that this problem is caused exclusively by the use of Moq. Otherwise you're asking at the wrong place.