3

我收到了一台新机器，并认为插入一些机器范围的重定向只适用于我的 FsCheck 测试，就像在我以前的机器上一样。

事实并非如此，我收到了 与旧机器上类似的错误，所以我知道这是 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 。可执行程序

=== 预绑定状态信息 ===

日志：DisplayName =FSharp.Core，版本 = 4.0.0.0，文化 = 中性，

调用程序集：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>
4

0 回答 0