Wrong FSharp.Core resolution for F# 4.0

[dungpa]

Tested with https://www.nuget.org/packages/FSharp.Compiler.Service/1.4.0-beta

FCS still uses FSharp.Core 4.3.0.0 as default. Consequently, any new functionality on FSharp.Core 4.4.0.0 doesn't work on scripts. This breaks all VFPT functionalities on scripts.

Here is a relevant log:

GetScriptCheckerOptions: Creating for stand-alone file or script: 'C:\Users\dungpa\Documents\GitHub\Script1.fsx'
GetScriptCheckerOptions: ProjectFileName: C:\Users\dungpa\Documents\GitHub\Script1.fsx.fsproj, ProjectFileNames: [|"C:\Users\dungpa\Documents\GitHub\Script1.fsx"|], FSharpProjectOptions: [|"--noframework"; "--warn:3";
"-r:C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0\System.Numerics.dll";
"-r:C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0\mscorlib.dll";
"-r:C:\Program Files (x86)\Reference Assemblies\Microsoft\FSharp.NETFramework\v4.0\4.3.0.0\FSharp.Core.dll";
"-r:C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0\System.dll";
"-r:C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0\System.Xml.dll";
"-r:C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0\System.Runtime.Remoting.dll";
"-r:C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0\System.Runtime.Serialization.Formatters.Soap.dll";
"-r:C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0\System.Data.dll";
"-r:C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0\System.Drawing.dll";
"-r:C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0\System.Core.dll";
"-r:C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0\System.Web.dll";
"-r:C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0\System.Web.Services.dll";
"-r:C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0\System.Windows.Forms.dll";
"-r:C:\Program Files (x86)\Microsoft SDKs\F#\4.0\Framework\v4.0\FSharp.Compiler.Interactive.Settings.dll"|], IsIncompleteTypeCheckEnvironment: false, UseScriptResolutionRules: true

[dsyme]

Hmmm. The FSharp.Core used for scripts is

1. the FSharp.Core statically referenced by the host process, or if there isn't one then
   2., the FSharp.Core statically referenced by the FSharp.Compiler.Service DLL

See https://github.com/fsharp/FSharp.Compiler.Service/blob/d5d42a436819af46c45b5c13131d0d29c3a7b55d/src/fsharp/build.fs#L1553.

I assume in your case the host process is VS2015 devenv.exe (which doesn't reference FSharp.Core directly). And the FSharp.Compiler.Service.dll references FSharp.Core 4.3.0.0. So that's consistent with what we see above.

It feels like the logic linked above needs modification. I think the right thing to do is to modify it to choose the "natural" version of FSharp.Core for the version of the F# language being supported by FCS if there is no explicit reference to FSharp.Core in the host process (i.e. replace choice 2 by having FCS 1.3.x choose 4.3.1.0 and FCS 1.4.x choose 4.4.0.0)

An alternative is to allow a target F# version to be passed into the GetScriptCheckerOptions call, rather than trying to be smart but I guess you can do that by being using explicit arguments.

Are you currently working around this problem by hacking the generated arguments?

Thanks
don

[dsyme]

@dungpa Could you see if that fix works for you? See nuget package at https://ci.appveyor.com/project/fsgit/fsharp-compiler-service/build/1.4.0.0-beta-b417/artifacts

I'm also curious what FSharp.Core gets implicitly referenced for scripts for the Visual F# Power Tools for VS2013 and F# 3.1 today. It seems to me that, according to the above analysis, FSharp.Core 4.3.0.0 should be being referenced. Do you replace that reference with 4.3.1.0, or are there some glitches associated with the 4.3.0.0 reference where scripts referencing 4.3.1.0 functionality don't get checked/refactored correctly? If so #385 adjusts the implicit reference for FCS 1.3.x.x

[dungpa]

Do you replace that reference with 4.3.1.0, or are there some glitches associated with the 4.3.0.0 reference where scripts referencing 4.3.1.0 functionality don't get checked/refactored correctly?

We didn't do any post-processing. The differences between 4.3.1.0 and 4.3.0.0 were so small that we didn't notice the glitches.

I don't think using #384 is enough for us. Our scenario is to use FCS 1.4.0.x and deploy it on VS 2015, VS 2013 and VS 2012. Based on VS version, we would like to have an option in GetScriptCheckerOptions to indicate which FSharp.Core version we prefer. Could you expose such an option?

[dsyme]

Do you do post-processing now for your trial vs2015 version? Does it work OK? If so, then you now effectively have a way of specifying the version (by processing the command=line arguments and adjusting the FSharp.Core reference)?

Giving an explicit way of specifying FSharp.Core version in GetScriptCheckerOptions would be a bit strange, since presumably it would only apply in the case where the host .EXE doesn't contain a static reference to FSharp.Core (or, perhaps, would override that logic). But it still feels fairly equivalent to post-processing the command-line arguments.

[dungpa]

Do you do post-processing now? Does it work OK? If so, then you now effectively have a way of specifying the version (by processing the command=line arguments and adjusting the FSharp.Core reference)?

Yes. It seems to work OK when I tested on VS 2015. I find cracking compiler arguments to be troublesome. What about .NET assemblies resolution in the log above? I suppose the referenced assemblies should no longer be in .NET 4.0. Is there any option in GetScriptCheckerOptions to have influences on the resolution process?

Yeah, deploying FCS 1.4.0.x on both VS 2015, VS 2013 and VS 2012 is strange. But it reduces maintenance overhead and it is tolerable since F# is generally backward compatible.

[dsyme]

Yes, the .NET 4.0 references are also incorrect for F# 4.0 scripts (and even F# 3.1 ones). I need to think about this, I will try to experiment with plumbing some kind of parameter through

[dungpa]

Thanks. And sorry for being demanding. We would like to have correct default resolution and a way to alter resolution for FSharp.Core and BCL core assemblies, for which we use at our own risk.

[7sharp9]

Incidentally it would be nice to be able to specify the default dll bindings in the interactive session too. By that I mean there are several different sets that are bound by default, there's a set for silverlight and one for desktop. I remember they were causing issues on the pcl FCS I was creating.

On 23 Jul 2015, at 23:54, Anh-Dung Phan notifications@github.com wrote:

Thanks. And sorry for being demanding. We would like to have correct default resolution and a way to alter resolution for FSharp.Core and BCL core assemblies, for which we use at our own risk.

—
Reply to this email directly or view it on GitHub.

[dsyme]

Closed by the above fixes. However we should also document how to post-hack the arguments for the scripting to reference a different FSharp.Core.