FSI integration is broken #465
Comments
|
@cartermp thoughts on if |
|
OK, so I've thought about it a bit...
|
|
What we want is (I think):
|
|
Cool. I think we can do both of those things just by using the FCS members with different args for useSdkRefs and assumeDotNetzframework. That'd be great. Then it just turns into a question of 'what API surface needs to change to allow us to choose an execution mode?'. |
|
Generally speaking the uptake on new .NET Core versions is super fast, so requiring .NET Core 3.0 isn't unreasonable, especially since by all accounts it's been a stable release. |
|
@cartermp Do we have any stats for that that you could potentially share? |
|
None that I know as sharable. But given that VS will give you the latest, it's quite high. For example, you get .NET Core 3.0 with VS 2019 16.3. |
|
Fixed by #466 |
|
For some reason, intellisense does not seem to be working in I noticed the following error in the output logs: Perhaps it's related to this PR? I'm currently running ubuntu 18.04, dotnet sdk 3.0.100, mono 6.0.0.319, and ionide 4.2.0. I'm also using the netcore version of fsac and Also my dotnet install path is Interestingly, installing FAKE seems to fix the problem. FSAC appears to detect that it's a fake script and handles it differently. |
|
The initial error you saw is because we assume the default dotnet sdk install location of /usr/local/share/dotnet. We'd need to add a way to discover your dotnet root before this would get fixed for you. |
|
Aww, geez. I totally missed that Thanks, @baronfel! |
|
It's something we can do better at for sure. Part of the nature of the SDK is that it can be installed anywhere, so to be 100% correct we'd need a discovery mechanism :-/ |
|
You know, while I was working with the previews, I ended up setting an env var called, |
|
Yeah, any discovery mechanism we did would probably look at
And maybe that's enough to cover most folks use cases. The hard part is doing that in ionide/other clients and passing that info into FSAC |
|
Yeah, adding setting and checking |
|
@HoraceGonzalez please check out #475 and leave any additional comments there |
Right now FSI fails in Ionide because we're computing the .Net Framework reference set for parsing script files instead of the proper reference set for .Net Core.
We should fix this, and the route we've chosen for now is to investigate the use of the
BackgroundCompiler.GetProjectOptionsFromScriptmethod in FCS, specifically using theuseSdkRefsandassumeDotNetFrameworkparameters.This works, mostly. Results are summarized in the following table:
On .net core, at least 2.1. The code paths all converge onto this function. This function seems to work for netfx and netcoreapp > 3.0 TFMs, because either desktop refs are ok or all necessary refs are in the 'pack' directories starting with 3.0.
For 2.x, once an mscorlib is added to the project options, then typechecking works. The problem seems to be that some deps are not available that the user might expect, ie System.Diagnostics.Process. I did some work to find the set of assemblies found in
dotnet fsi:dotnet fsi reference set
and the ones discovered in netcoreapp2.1 _that aren't in dotnet fsi`:
netcoreapp2.1 - dotnet fsi assemblies
And that's where we are right now. We have a working proof of concept, but we'd like to
a) PR adding mscorlib to the default reference set, and
b) figure out which assemblies need to be added to the netcoreapp2.x reference set.
Solving this in a way that includes
FSharp.Compiler.Interactive.Settingsin the references set all the time would also fix #227.The text was updated successfully, but these errors were encountered: