我收到了一台新机器，并考虑插入一些machine wide redirect would just work，因为我的FsCheck测试会像我以前的机器一样工作。
情况并非如此，我收到similar error than on my old machine所以我知道FsCheck加载F＃4.X而我的测试绑定到其他一些版本4.Y
启用FusionLog后，重新启动以激活该野兽，为所有绑定启用fusionlog，重新启动。我在日志中找到了罪魁祸首：
装配管理器从以下位置加载：
C：\ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ clr.dll正在运行 可执行文件C：\ PROGRAM FILES（X86）\ MICROSOFT VISUAL STUDIO 11.0 \ COMMON7 \ IDE \ COMMONEXTENSIONS \ MICROSOFT \ TESTWINDOW \ vstest.executionengine.x86.exe
===预绑定状态信息===
日志：DisplayName = FSharp.Core，Version = 4.0.0.0，Culture = neutral，
调用程序集：FsCheck.Xunit，Version = 0.3.0.0，Culture = neutral，PublicKeyToken = null。
我对绑定不太熟悉，但是：
为什么fscheck在运行测试之前没有抱怨它可以找到正确的dll而不是在运行时崩溃。我很想知道处理这种问题的优雅方法是什么
为什么fscheck尝试加载版本4.0.0.0（如果它与它不兼容）。再次，试图理解我必须缺少的东西，因为它听起来非常明显。 我想这不是支持4.X VS 4.Y的问题，但更多的是'跑步者'到4.X而且fscheck被绑定到4.Y（是吗？在这种情况下，什么会阻止''重用'第一个绑定？）
为什么我的机器范围重定向被忽略了。我认为它的优先级低于任何其他本地配置文件，但不应该在解决之前的某个阶段对dotnet框架进行调查。
很明显，我将以下内容添加到vstest.executionengine.x86.exe.config以避免4.0.0绑定，但我仍然对我的无知和我们的“框架”变幻莫测引起的变迁感到困惑：
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="FSharp.Core" publicKeyToken="b03f5f7f11d50a3a"
culture="neutral"/>
<bindingRedirect oldVersion="4.0.0.0" newVersion="4.3.0.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>