3

I received a new machine and thought plugging in some machine wide redirect would just work for my FsCheck tests would work like in my previous machine.

That was not the case, and I received a similar error than on my old machine so I knew that it was FsCheck loading F# 4.X while my tests were binding to some other versions 4.Y

After enabling FusionLog, rebooting to activate that beast, enabling fusionlog for all binding, re-rebooting. I found the culprit in the logs :

Assembly manager loaded from:

C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll Running under executable C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO 11.0\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\TESTWINDOW\vstest.executionengine.x86.exe

=== Pre-bind state information ===

LOG: DisplayName =FSharp.Core, Version=4.0.0.0, Culture=neutral,

Calling assembly : FsCheck.Xunit, Version=0.3.0.0, Culture=neutral, PublicKeyToken=null.

I am not too familiar with binding but :

  • Why fscheck does not complain before running the tests that it cnat find the correct dll instead of crashing at runtime. I am interested in knowing what could be the graceful way to handle such problem

  • Why is fscheck trying to load the version 4.0.0.0 if it is not compatible with it. again,trying to understand what I must be missing as it sounds very obvious. I imagine this is not a matter of supporting 4.X VS 4.Y but more the 'runner' being boud to 4.X while the fscheck being bound to 4.Y (is it ? in which case, what would prevent the 'reuse' of the first bindings ?)

  • Why is my machine-wide redirect ignored. I imagine it has lower priority than any other local config file, but shouldn't the dotnet framework look into it at some stage before resolution.

Obvisouly I added the following to vstest.executionengine.x86.exe.config to avoid 4.0.0 binding, but am still puzzled by the vicissitudes induced by my ignorance and the vagaries of our 'Framework' :

<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>
Community
  • 1
  • 1
nicolas
  • 9,549
  • 3
  • 39
  • 83
  • I don't know the answer to your question, but I'd like to point out that FsCheck is compatible with 4.0.0.0, and that's what it's trying to load. What's happening is that your other code is compiled against 4.3, and then the crash at runtime usually happens because of what I call "type confusion": a 4.0 tuple is not the same as a 4.3 tuple, and so on for all FSharp.Core types, so usually some runtime cast from Tuple<..> to Tuple<..> goes wrong. – Kurt Schelfthout Mar 05 '13 at 12:46
  • So the binding redirect should tell .NET to load 4.3 no matter what version FsCheck (or other dlls) is compiled with. And then the confusion does not happen. – Kurt Schelfthout Mar 05 '13 at 12:47
  • @KurtSchelfthout that is what I suspected regarding FsCheck. the problem comes from the difference not the particular version. however, I am lacking understanding of the grand scheme of things. As it is not the first time I get stung, I imagine other people have also. – nicolas Mar 05 '13 at 14:17
  • The redirect in app.config works fine. I'm not sure about machine wide... – Kurt Schelfthout Mar 06 '13 at 19:43
  • For whichever app you are running. Probably a test runner or test executable. Can be hard to figure out if you use some VS built-in test runner...also, some unit testing frameworks (like xunit I believe) actually use the app.config of your test.dll... – Kurt Schelfthout Mar 07 '13 at 18:25
  • NUnit and (I believe) XUnit will load `app.config`s of test dlls. (Which get renamed during the compilation process to Assembly.Name.dll.config rather than .exe.config). – mavnn May 23 '13 at 08:37
  • By the way, since 0.9 the nuget package for FsCheck is compiled for 4.3. So hopefully that removes this problem altogether. – Kurt Schelfthout Jul 05 '13 at 01:13

0 Answers0