By default compilations using FCS reference FSharp.Core 4.3.0.0

[quasilord]

If no FSharp.Core/mscorlib is referenced when using the "Compile" method in SimpleSourceCodeServices, then FSharp.Core 4.3.0.0 is referenced by default. This has been the cause of some failures on Appveyor.

See https://github.com/fsharp/FSharp.Compiler.Service/blob/13982fa12e0bacaa91e16cced40776fbeb1f77ff/src/fsharp/build.fs#L1563 (FSharp.Compiler.Service.dll itself references FSharp.Core 4.3.0.0, making it usable as widely as possible)

Ramifications:

• programs compiled with FCS using the implicit default FSharp.Core can't be run on machines where FSharp.Core 4.3.0.0 aren't in the GAC (e.g. machines with only VS2013 installed).
• the behavior of "FscTest.exe" in FCS differs from the behavior of "fsc.exe" in F# 3.1

FCS should probably default to referencing the version of FSharp.Core in the process hosting FCS, rather than the version referenced in the DLL (these may be different via a binding redirect)

[dsyme]

Good investigation - it would be great to see this fixed

[forki]

same issue in FSharp.Formatting.dll

[dsyme]

Can you provide an explicit reference to an FSharp.Core? What's your build context here - how do you know which .NET Framework etc. (and FSharp.Core) is referenced by the compilation you're building documentation for?

[forki]

Since FAKE 3.0 we use the FCS directly in FAKE. FAKE comes with FSharp.Core 4.3.1.0 and has AssemblyReferenceRedirect which also uses 4.3.1.0. FCS.dll doesn't respect this, so FAKE scripts fail on some build servers.

The proposed change in #172 resolves this. I put a hacked FCS.dll in the FAKE 3.0.4 nuget package and people report that it works (see fsprojects/FAKE#486).

My problem with FSharp.Core.dll resolution in FSharp.Formatting is also fixed when I apply this change.