How to Check .Net and F# Core Versions on Target System

I have written a simple F# console applet. It is built against .Net Framework 4.5 and F Sharp Core 4.0. It runs fine on my Windows 10 workstation. On Windows Server 2016 (Version 1607) it throws

Unhandled Exception: System.TypeInitializationException: The type initializer for '<StartupCode$VolLib>.$VolLib' threw an exception. ---> System.IO.FileLoadException: Could not load file or assembly 'FSharp.Core, Version=4.3.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

I have tried the substitutions suggested in this post. I still get the same error.

I can install a kit on the server (target machine). I just don't know what to install.

This is usually a binding issue, not a framework issue. 4.3 is the older version.

Most likely, the 4.3 version is installed in the GAC of the server. Less likely, the bin dir contains the wrong F# version, but the offending method is not called on the Win10 system. Check the output dir and the GAC for the FSharp.Core.dll versions, if they are correct, check BindingRedirect in app.config.

If this doesn't help finding the location and version of the wrongly linked dll, alternatively, dump the Core assembly version with typeof<option>.Assembly.GetName().Version as one of the earliest in your code (use Console.WriteLine, not printfn). You can also dump the actual path of the location of the assembly this way.

The usual reason this happens is because your code compiles with a library that itself is compiled against an older version of FSharp.Core (like for instance FParsec, it's a common issue with that library). I've had cases where the wrong assembly was then deployed, or the right one, but without the BindingRedirect it failed anyway.

If you want to know which linked assembly is the culprit, you'll have to check for each of them what F# version they've been compiled against. A tool like Reflector can help. If you you want to dig deeper into the assembly loading resolution, you can use the fuslogvw.exe tool for real time logging of binding events.

Btw, you can get the current version of the framework you're running in with System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription