3

私は新しいマシンを受け取り、以前のマシンと同じように FsCheck テストが機能するように、マシン全体のリダイレクトをプラグインするだけで機能すると考えました。

そうではなく、 古いマシンと同様のエラーを受け取ったので、テストが他のバージョン 4.Y にバインドされている間に、FsCheck が F# 4.X をロードしていたことがわかりました。

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、バージョン = 4.0.0.0、カルチャ = ニュートラル、

アセンブリの呼び出し: FsCheck.Xunit、Version=0.3.0.0、Culture=neutral、PublicKeyToken=null。

私はバインディングにあまり慣れていませんが、

  • 実行時にクラッシュするのではなく、正しい dll を見つけることができるというテストを実行する前に、fscheck が文句を言わないのはなぜですか。そのような問題を処理するための優雅な方法を知りたい

  • バージョン 4.0.0.0 と互換性がない場合、fscheck がバージョン 4.0.0.0 をロードしようとするのはなぜですか。繰り返しますが、私が見逃しているに違いないことを理解しようとしています。これは 4.X VS 4.Y をサポートする問題ではなく、fscheck が 4.Y にバインドされている間に「ランナー」が 4.X にバインドされていることだと思います (そうですか?その場合、「最初のバインディングの再利用 ?)

  • マシン全体のリダイレクトが無視されるのはなぜですか。他のローカル構成ファイルよりも優先度が低いと思いますが、解決前のある段階で dotnet フレームワークがそれを調べるべきではありません。

明らかに、私は 4.0.0 バインディングを避けるために以下を追加しましたvstest.executionengine.x86.exe.configが、私の無知と私たちの「フレームワーク」の気まぐれによって引き起こされた変動にまだ困惑しています:

<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