The following code should compile (and does in FSI as well as in VS2019's .fsx editor).
#load @".paket\load\Expecto.fsx"
#r "netstandard"
open Expecto
let tests =
test "A simple test" {
let subject = "Hello World"
Expect.equal subject "Hello World" "The strings should equal"
}
However in Ionide this gives an error that you must first reference netstandard (which, as you can see, has been done above). In VS2019 if I remove the #r directive, I get the same error.
Interesting, referencing https://github.com/dotnet/fsharp/issues/5216 here.
Considering the last comment, I guess it should "just work" for latest FCS. Maybe we somewhere have a different target framework setup and not net472?
I don't understand at all how .fsx files works in context of tooling
"Magic". I guess it is just a regular call to the F# tooling (FCS) with the default framework references. I haven't looked at the code but we either:
maybe @enricosada knows more?
I guess it is just a regular call to the F# tooling (FCS) with the default framework references
Yes, I know as much ;-)
We're indeed using FCS resolution - https://github.com/fsharp/FsAutoComplete/blob/master/src/FsAutoComplete.Core/Commands.fs#L384 - however I don't know how it works in context of:
net vs netcore)fsi.exe vs dotnet fsi)I think the story is that currently you cannot detect everything. So fsi/scripting is backwards compatible upgrade only.
If your editor is newer you might use features not available in the fsi you are running later. Or if your editor is older it shows errors which are not actually errors (like this issue).
There is currently no story. As this is a problem for "netcore" scripting the F# team will probably solve this somehow. I guess the solution will be some #netcore directive at the top (or something similar). Imho this is one of the reasons netcore scripting took/takes so long?
This obviously is not a real solution but it will be enough until next major .NET ;)
@matthid what's the workaround for right now? Currently Ionide is dead in the water if you're using netstandard packages in a script?
Ok. I think I have a (flakey?) workaround:
By explicitly referencing a specific version of netstandard in netcore (rather than framework), it seems to work:
#r @"C:\Program Files\dotnet\sdk\3.0.100-preview7-012821\ref\netstandard.dll"
FsAutoComplete calls checker.GetProjectOptionsFromScript(file, text)
I have tried looking at the code but I guess nobody really knows at this point what that thing does by default. I would even go as far as nobody even knows what it should be doing. The whole thing is basically a huge hack.
I can only tell what FAKE is doing: It just downloads Netstandard.Library and uses the reference assemblies for compilation. Maybe Ionide can do something similar? I guess it has to use the full framework for now (for compat reasons with older scripts, so Ionide could, for example, download the Microsoft.NETFramework.ReferenceAssemblies package?)
As it is "only tooling" it shouldn't matter that we use reference assemblies as we don't need to run anything.
@isaacabraham Another workaround is to change your script to a FAKE script, that should work as well (no need to actually run it with FAKE, but just trick vscode to detect it as such with a FAKE header).
@matthid how do you mean, change it to a FAKE script?
just add a fake header with your dependencies but run it as before with fsi (you can use #if FAKE)
Should be fixed in 4.2.0
I still see this in 4.2.0 - squiggles under:
Created a brand new f# project using "F#: New Project" and added a .fsx file with above line.
Latest Ionide has the same issue with a script:
I'm using the netcore version of FSAC.
Making sure: do you have useSdkScripts set to true?
I found the root cause for @isaacabraham's FSharp.Data conunudrum and we'll hope to have that out in the next release.
That should be fixed in 4.3.1, right?
Yes, can confirm that this looks to be fixed in latest Ionide.
Most helpful comment
I found the root cause for @isaacabraham's FSharp.Data conunudrum and we'll hope to have that out in the next release.