FSharp Language Server stopped working and now only produce problems

[Brodersen]

With an fsx file containing only let x = 3 I get the following problems and red lines in vs code:

parameter: The type provider '/Users/gabriel/.vscode/extensions/georgewfraser.fsharp-language-server-0.1.27/src/FSharpLanguageServer/bin/Release/netcoreapp3.0/osx.10.11-x64/publish/FSharp.Data.dll' reported an error: Assembly attribute 'TypeProviderAssemblyAttribute' refers to a designer assembly 'FSharp.Data.DesignTime' which cannot be loaded or doesn't exist. Could not load file or assembly '/Users/gabriel/.vscode/extensions/georgewfraser.fsharp-language-server-0.1.27/src/FSharpLanguageServer/bin/Release/netcoreapp3.0/osx.10.11-x64/publish/FSharp.Data.DesignTime.dll'. The system cannot find the file specified.

Running dotnet --info I get:

.NET Core SDK (reflecting any global.json): Version: 3.1.200 Commit: c5123d973b

Runtime Environment: OS Name: Mac OS X OS Version: 10.15 OS Platform: Darwin RID: osx.10.15-x64 Base Path: /usr/local/share/dotnet/sdk/3.1.200/

Host (useful for support): Version: 3.1.2 Commit: 916b5cba26

.NET Core SDKs installed: 3.1.200 [/usr/local/share/dotnet/sdk]

.NET Core runtimes installed: Microsoft.AspNetCore.App 3.1.2 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.NETCore.App 3.1.2 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

[georgewfraser]

Hmm, this seems to be a regression with the update to 3.1. This only seems to be happening for .fsx files, not .fs files. Probably what needs to be done is for the analyzeFsx code path:

https://github.com/fsprojects/fsharp-language-server/blob/94dadf2eb1e2eb9b17e1d119bc33f9a63e4c6417/src/FSharpLanguageServer/ProjectManager.fs#L240

to be updated in the same way analyzeFsproj was:

https://github.com/fsprojects/fsharp-language-server/blob/94dadf2eb1e2eb9b17e1d119bc33f9a63e4c6417/src/FSharpLanguageServer/ProjectManager.fs#L263

was in this PR:

https://github.com/fsprojects/fsharp-language-server/pull/70

@adamnew123456 @PhilT looking at the analyzeFsx, does the answer jump out to you?

[PhilT]

In Neovim on Windows 10 I get something slightly different.

[undefined] [E] parameter: System.IO.FileLoadException: The given assembly name or codebase was invalid. (0x80131047)
   at System.Reflection.AssemblyName.nInit()
   at System.Reflection.AssemblyName..ctor(String assemblyName)
   at FSharp.Compiler.SimulatedMSBuildReferenceResolver.SimulatedMSBuildResolver@28.FSharp-Compiler-ReferenceResolver-Resolver-Resolve(ResolutionEnvironment resolutionEnvironment, Tuple`2[] references, String targetFrameworkVersion, FSharpList`1 targetFrameworkDirectories, String targetProcessorArchitecture, String fsharpCoreDir, FSharpList`1 explicitIncludeDirs, String implicitIncludeDir, FSharpFunc`2 logMessage, FSharpFunc`2 logWarningOrError) (Code=SR001)

I've never looked at this codebase so don't have the first clue what it could be.

[georgewfraser]

@PhilT didn't you work on the changes to ProjectManager for 3.1? Or did I just get confused by the comment stream?

[PhilT]

No, @georgewfraser I just did a bit of testing

[georgewfraser]

Oh. Well, maybe @adamnew123456 will take a look soon.

[adamnew123456]

Hm. While I can't reproduce this exactly, the underlying cause of the problem seems to be the same as what I'm seeing. I get something about FSharp.Data.dll not having any type providers, because of an assembly it couldn't load.

My guess is that we're having a problem finding these assemblies because we're referencing the compiled output of FSLS itself instead of the .NET Core assemblies themselves. Partially this is code in FSLS (typeof<System.Object>.Assembly.Location), but it also seems to be the behavior of whatever provides FSharpChecker since it does the same thing with non-framework paths.

/home/chris/Tmp/logs/main.fsx.fsproj: 
  ProjectFileName: "/home/chris/Tmp/logs/main.fsx.fsproj"
  SourceFiles:
    - /home/chris/Tmp/logs/utils.fsx
    - /home/chris/Tmp/logs/main.fsx
  ReferencedProjects:
  OtherOptions:
    - -r:/home/chris/Apps/FSharpLanguageServer/master/bin/FSharp.Core.dll
    - -r:/home/chris/Apps/FSharpLanguageServer/master/bin/Microsoft.CSharp.dll

I'm thinking that we could try to detect the "fake" framework prefix (e.g. /home/chris/Apps/FSharpLanguageServer/master/bin/), strip it from each of the referenced paths we get back and insert the .NET Core prefix using a similar method to ProjectCracker.parseProjectAssets.findRuntimePaths. Of course we don't have any way to direct our choice of framework like we would in the project.assets file, but we can just pick the latest framework and go with it.

After that process, any file which gets substituted and doesn't exist in the framework should just get dropped, which would fix the FSharp.Data thing. Hopefully this doesn't conflict with assemblies referenced from NuGet, but I'll test that case when I've committed the change locally.

[adamnew123456]

@PhilT @Brodersen could you try this with the issue-78 branch on my repo, https://github.com/adamnew123456/fsharp-language-server/tree/issue-78?

I made the changes outlined in the last comment and they seem to be working fine for both the core framework assemblies (FSharp.Core Arrays, List, etc. and System.*) as well as some assemblies currently in my ~/.nuget. I get completion and type info for everything without any spurious errors.