FSharp.Compiler.Interactive.Settings seemingly not part of script references

[baronfel]

@kevmal on the F# foundation slack shared an image of a typecheck error he had in a fsx script. He's on 2019 16.4, and after looking at the DotNetFrameworkDependencies.fs file I think I see what the problem is.

I believe the issue comes from here, where the string "FSharp.Compiler.Interactive.Settings" is passed as one of the dependencies to be resolved by getDependenciesOf. getDependenciesOf has some handling for 'simple names', that is assembly names that are not full file paths: it prepends the framework directory to the simple name and attempts to resolve that reference.

In this case I think this logic is incorrect, because the "FSharp.Compiler.Interactive.Settings" reference is colocated with the compiler, not with the rest of the framework references. I think that in this case, the assembly should be manually resolved by joining the simple name with the already-defined getFSharpCompilerLocation path, which should be correct.

Repro steps

1. Create an fsx script in VS 2019 16.4
2. use any member of the fsi binding.

Expected behavior

The fsi binding's members are available in-editor.

Actual behavior

The fsi binding's members are not available.

Known workarounds

The user can always provide an explicit #r reference to the dll, but this is non-portable.

Related information

Provide any related information (optional):

• Operating system: Windows
• .NET Runtime kind: .NET Core 3.x
• Editing Tools: Visual Studio 2019 16.4

[dsyme]

As far as I can tell this is a regression in Visual Studio 16.4.1

[dsyme]

Script files are now missing implicit references to FSharp.Compiler.Interactive.Settings.dll when editing. It also seems impossible to workaround this by adding #r “FSharp.Compiler.Interactive.Settings”

This means simple code like the following now shows red squigglies when editing:

	fsi.PrintLength <- 100

[dsyme]

so this is definitely covered by the language service testing, what's happened....

fsharp/vsintegration/tests/UnitTests/LegacyLanguageService/Tests.LanguageService.Script.fs

Line 1162 in 4363f4c

member public this.``Fsx.BugAllowExplicitReferenceToMsCorlib``() =

fsharp/vsintegration/tests/UnitTests/LegacyLanguageService/Tests.LanguageService.Script.fs

Line 1179 in 4363f4c

"fsi."

fsharp/vsintegration/tests/UnitTests/LegacyLanguageService/Tests.LanguageService.Script.fs

Line 1203 in 4363f4c

AssertArrayContainsPartialMatchOf(fas.OtherOptions, "FSharp.Compiler.Interactive.Settings.dll")

I checked those tests are reported as running and passing:

√ Fsx.Bug2530FsiObject [241ms]

https://dev.azure.com/dnceng/public/_build/results?buildId=455447

So I suppose there's a difference between the setup/references when testing and the actual deployed setup.....

[dsyme]

You can workaround this to some extent by the following (adjust the path as necessary)

#if EDITING
#r @"C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\CommonExtensions\Microsoft\FSharp\FSharp.Compiler.Interactive.Settings.dll"
#endif

The good thing about this workaround is that it doesn't affect the execution of scripts, though the hard coded path is obviously problematic for editing across teams and for cross-platform scripts.