4.2.0 - No auto complete or typechecking in FSX files

[mvkara]

Not getting auto complete and type checking in FSX files. F# logs complain about a missing "mscorlib.dll" and type checking is aborted. Apologies if this is already reported.

I get the below in the F# output.

[Checker] ParseAndCheckFileInProject - .../script.fsx completed with errors [unknown (1,1)-(1,1) parameter error Assembly reference 'mscorlib.dll' was not found or is invalid]

To Reproduce
Steps to reproduce the behaviour:

1. Create new workspace
2. Make sure your using Ionide 4.2.0
3. Enter script
4. F# logs show that type checker can't find reference to mscorlib.dll.
5. No intellisense at all in FSX files even a blank one.

Expected behaviour
Type checking and auto complete should work as normal.

Environment (please complete the following information):

• OS: Mac OS Mojave
• Ionide version: 4.2.0
• VSCode version: 1.39.1
• dotnet SDK version: 3.0.100
• mono / .Net Framework version: 6.0.0.327

Additional context
If I downgrade to 4.1.0 it all works again. Admittedly it complains about System.Object being missing and I have to reference the facade netstandard assembly with an absolute path #r "/usr/local/Cellar/mono/6.0.0.327/lib/mono/4.5/Facades/netstandard.dll" on the top of my script but it still works. Get same behavior on my other Linux machine. Both Net FSI and new Net Core FSI don't work at all.

[open-collective-bot]

Hey @mvkra 👋,

Thank you for opening an issue. We will get back to you as
soon as we can. Also, check out our OpenCollective and consider
backing us.

https://opencollective.com/ionide

PS.: We offer backer support for all backers. Don't forget to add backer label when you start backing us 😄

[jfrank-summit]

I am also having this issue. Is anyone working on it? I've had this on and off for months...

[Krzysztof-Cieslak]

CC: @baronfel

[baronfel]

Hey folks, yes we're aware of this problem. We've got a few changes coming in FSAC specifically related to this problem that I hope will either fix it outright, or allow you to fix it with a configuration setting. Some background:

• on .net framework/mono, the directories that contain the 'reference assemblies' for FSX scripts were located in a few places. These places were hardcoded and given to use by the compiler itself. That's why FSX scripts tend to work if you use fsacRuntime: net and have .net framework/mono installed. However, these assemblies are not correct for use in .Net core.

• for .net core, the paths given to use by the compiler were/are incorrect. The assemblies we want to use are in certain convention-based locations that are relative based on the version of the .Net core SDK version that you are using, and it is actually very hard at run-time to derive those locations. I had to reimplement this logic for FSAC to get the locations and derive a valid set of 'reference assemblies'. However, to do this for our first pass attempt I hard-coded some assumptions about where the different versions of the dotnet SDK were installed. Those assumptions do not pan out for everyone.

• therefore, in subsequent versions of FSAC/Ionide, we will

  • expose a new setting that lets you tell us where your dotnet SDK installs are. This should ensure that we can find the required reference assemblies if in the worst case we can't locate them through our own logic.
  • provide new diagnostics that will provide us (as ionide/fsac maintainers) with enough context to hopefully diagnose the issue with loading at that point in time.

It's important to realize that almost every issue with FSX support in Ionide comes down to locating these assemblies. Once those are found, everything drops into place. So it's critical that we find them consistently and/or tell you, the user, why we couldn't find them.

I hope this explains the problem to a greater degree and illustrates why a full fix is taking a bit.

[baronfel]

Please try with the newly-released version of Ionide.

[mvkara]

The type checking at least works for framework assemblies after the update; however I can't seem to get any references loaded into the context for type checking using "#r" commands at present. Any types from referenced assemblies can't be found except of course framework assemblies after setting the required path to the .NET SDK. No errors I can see on the logs; its more that they seem to be ignored entirely. #load scripts however do work.

[baronfel]

Yes, that's another issue that I already have a PR in for. The issues fixed in this most recent release where hiding the issue you describe.

[Krzysztof-Cieslak]

Latest changes released in 4.3.1

[mvkara]

It's getting better. Had to set the dotnet sdk path "/usr/local/share/dotnet" and set the "Use SDK Scripts" to true in the ionide settings. Everything now works but there is a cosmetic glitch. At the very start of the F# script you get a set of "red squiggly line" errors like:

Assembly reference 'System.Runtime.Remoting.dll' was not found or is invalidF# Compiler(84)
Assembly reference 'System.Runtime.Serialization.Formatters.Soap.dll' was not found or is invalidF# Compiler(84)
....

[dgrimmin]

@mvkra I can confirm the same result. Execution of my fsx file into 'dotnet fsi' works fine.

Assembly reference 'System.Runtime.Remoting.dll' was not found or is invalidF# Compiler(84)
Assembly reference 'System.Runtime.Serialization.Formatters.Soap.dll' was not found or is invalidF# Compiler(84)
Assembly reference 'System.Web.Services.dll' was not found or is invalidF# Compiler(84)
Assembly reference 'System.Windows.Forms.dll' was not found or is invalidF# Compiler(84)

[baronfel]

I see that too in my testing, but the good news is that it's a cosmetic glitch only. The bad news is that I have zero idea so far where those references are being required from...

[dgrimmin]

I have to add that I am working on a Windows 10 system with only dotnetcore3.0 framework related installs. So no VS install, only VScode insiders version and Ionide ofcourse.

Today I was actually experimenting to get to the minimum install base, and I am impressed that the install base mentioned above actually works! Makes me proud to be a backer of the project.

So the cosmetic part may come from some .NET framework related ref?

[baronfel]

I'm not so sure about that, we only pull references from the packs/microsoft.netcore.app.refs/3.0.0/refs/netstandard3.0 directory of your dotnet sdk install, and all of those refs should be cross platform (seeing as they are part of the xplat sdk install :)). For example system.windows.forms.dll isn't in that directory at all!

[dgrimmin]

I take it dotnet fsi uses that same information? If so, then there must be on the Ionide side some dangling ref to .NET framework stuff.

[dgrimmin]

Or netstandard2.0...

[mvkara]

@dgrimmin Or it could be that potentially there's references somewhere (FSI code/F# compiler) to older non-ported to NET Core assemblies that are still present in the .NET Framework.

@baronfel i.e. Remoting, Winforms, Serialisation.Soap, etc all look like assemblies that would of NOT been ported to .NET Core from .NET Framework so they shouldn't be in that directory. Since Mono probably has these somewhat implemented this wasn't a problem for the old .NET FSI. Maybe this problem is even further upstream in the F# Compiler/FSI code.

[baronfel]

@mvkra that's more what I was thinking yes, since I've seen the entire set of references going into the compiler for the script file (another piece of info I'd like to expose in ionide :) ). But as of yet I don't have proof to submit upstream to dotnet/fsharp

[baronfel]

The cosmetic issue is tracked at ionide/FsAutoComplete#503, and the MR that fixes it is ionide/FsAutoComplete#504 (turns out it was user error, but the API is totally non-obvious).

[dgrimmin]

@baronfel and @mvkra, thank you for tracking this. Looking forward to the release!

[Krzysztof-Cieslak]

All the fixes to the scripting got merged in FSAC and now stuff should be better.