Ionide-vscode-fsharp: Ionide 4.0 roadmap

[Krzysztof-Cieslak]

In https://github.com/dotnet/fsharp/issues/6785 I've talked a bit about upcoming Ionide 4.0. In this issue I'll track main work items that will lead to the release. We will use experimental-fsharp extension to distribute previews. Version 3.X of Ionide is not officially feature-frozen, however it's hard to expect any new huge features in the current state. The work will be happening on 4.0 branch

Roadmap:

• [x] Use LSP version of FSAC (https://github.com/ionide/ionide-vscode-fsharp/pull/1109)
• [x] Use netcore runtime of FSAC as default (#1114)
• [x] Remove multiple ways of workspace initialization - we will use only workspace method (#1114)
• [x] Use new unified project parsing in FSAC (https://github.com/fsharp/FsAutoComplete/pull/347)
• [x] Use .Net Core version of Forge (#1113)
• [x] ~Update Forge scaffolding to use dotnet new under the hood~ Use .Net Core Forge templates (#1113)
• [x] Replace project parsing notification with status bar indicator (https://github.com/ionide/ionide-vscode-fsharp/issues/1077)
• [ ] Add support for .Net Core FSI (https://github.com/ionide/ionide-vscode-fsharp/issues/1087)
• [x] Rethink the default settings - things like external autocomplete, simplify names analyzer or background project checking should probably be turned off by default

[MangelMaxime]

Remove FSAC runtime option - we will distribute only .Net Core version of FSAC

Just a warning about this decision. I know that at least one of my project can't use .Net Core runtime anymore due to a SO in the F# Compiler.

I think that I have more than one project doing that but I need to check again.

Original issue: https://github.com/ionide/ionide-vscode-fsharp/issues/1039

[baronfel]

Same for us, the underlying stackoverflow still isn't solved for some of our projects.

[Krzysztof-Cieslak]

Yes, I'm aware of the issue - if that won't be fixed when Ionide 4.0 will be ready, we will keep net runtime, but will use netcore as default.

[enricosada]

@Krzysztof-Cieslak @baronfel I am not sure if FCS .net core can fully support fsx script on .NET fsi. Or some .NET projects if that matter.
I seen small quirks who add up, i'll list these somewhere later, but is not just project parsing.

For sure, i agree that the .NET Core stack should be the default, for best experience for new and existing users, as @cartermp suggested.

.NET Core will be the future, but .NET is important, lot of libs atm.

I think a safer bet is have both stack, but an easier way to choose, not the multiple independent options ( (fsi/fsac/msbuild) we have now who are confusing like msbuild vs dotnet msbuild. We need to simplify:

users doesnt care about FSAC/msbuild version. just a bit more the fsi version

• FSAC/FSI/MSBUILD are aligned. Or are .NET or .NET Core.
• when .NET => fsac .NET + fsharpi + msbuild
• when .NET Core => fsac .NET Core + dotnet fsi + dotnet msbuild

Default is .NET Core stack

FSI

As a note, the dotnet fsi is in preview.

Another stuff i am thinking can help:

• fsx script are a bit strange, until dotnet fsi is out preview, but also after that.
• each fsx script is isolated, is alongside the fsproj but usually have different references, etc
• and maybe is a expected to run with fsi, the #r matter there.

So i think we should threat .fsx and .fs differently.

• each FSI should start a new FSAC. so isolated. Easy to kill when FSI console is closed
• because FSI is separated, it can run on .NET or .NET Core as needed, without switching main FSAC

[Krzysztof-Cieslak]

msbuild vs dotnet msbuild

It doesn't depend on the FSAC runtime, tho - it depends on the project type, and both runtimes support both project types (i.e FSAC netcore can be run against MsBuild 14.0 file that needs to be build with msbuild). I feel we're doing good job in automatic detection of the msbuild host at the moment - personally, I haven't seen any case where I need to change host manually (but I'm not huge TP users, as far as I remember it was one of the cases where the change was needed).

I think that:

• msbuild vs dotnet msbuild - stays at it is, it's independent from the FSAC, the flow around building/running projects is OK, we have automatic detection of host.
• fsharpi vs dotnet fsi - controlled by option with dotnet fsi as default
• fsac netcore vs fsac net - The SO bug is only reason I'll consider keeping net. If some other stuff is not working in netcore we should fix it, instead of distributing net as workarond

[enricosada]

It doesn't depend on the FSAC runtime, tho - it depends on the project type

It's not so easy, and we work a lot on that, so i understand is more complicated for users.

It's:

• Old sdk project (verbose) = 100% .NET stack => msbuild
• .NET sdk project (slim), can be better msbuild or dotnet msbuild, depends on the sdks/target/packages used. But dotnet msbuild as sane default

But if they choose .NET stack (so msbuild), is fine to use FSAC .NET because it's expected .NET to exists.

Again, the root issue is .NET stack vs .NET Core stack, we should add just an option for that, with a sane default who command the other three (msbuild,fsac,fsi)

As a note, VS/rider use .NET stack.
Ionide doesnt need to do the same, is better the .NET Core stack, but we need choice

fsharpi vs dotnet fsi - controlled by option with dotnet fsi as default

Because is a binary choice, and can vary from script to script, ihmo a config is more work and too hidden when ppl doesnt know about the difference between the two, less so know a config.

Maybe it's better having two commands, something like:

• F# > Start Interactive (dotnet fsi) - runs on .NET Core [preview]
• F# > Start Interactive (fsi) - runs on .NET/mono

Or we can add a F# > Start FSI (more info) where you choose the version (dotnet fsi vs fsi), and maybe can pass additional args

We can also default FSI based on the current stack (.NET or .NET Core) for the repo

Again, dotnet fsi is preview, forcing preview for everyone has default create more issues.
Like:

• ppl load net461 libs and doesnt works
• do #r of GAC'ed libs
• follow tutorials (99.99% expect .NET, not .NET Core)
• send references of net461 project to fsi and these doesnt work.
• open fake v4 script

So a more explicit control with a command ihmo is less error prone.

If some other stuff is not working in netcore we should fix it, instead of distributing net as workarond

Is not so easy, otherwise all applications where already running on .NET Core only :(
There are limitatins based on .NET Core Runtime version.
Not everyone use latest 3.0 preview, and ihmo folks shouldnt use preview unless they know what they do, it's bad, it 99% better use latest LTS. Also Current have small niche usage.

Yes, we need to list and try to minimize differences, that's what everyone is doing, but take time, we are not yet there.

[Krzysztof-Cieslak]

OK, it seems we'll keep net FSAC runtime for a time being, but use netcore as default. I'll update OP

[inosik]

Update Forge scaffolding to use dotnet new under the hood

FYI, there's a new extension that provides a GUI for dotnet new. It won't work right now because the VSIX is missing the HTML file for the webview.

One issue I have with dotnet new though, is that we have to reinstall templates if we upgrade the .NET CLI. For example, if you're using .NET SDK 2.1.506 and do dotnet new -i SAFE.Template, you have to do this again after upgrading the .NET SDK to 2.1.507. We might be able to work around this if Forge would host the templating engine itself (dotnet/templating#1707) and configure the hive path in another way.

[Krzysztof-Cieslak]

Latest update:

• Use LSP version of FSAC - done in #1109
• Use .Net Core version of Forge - done in #1113
• Update Forge scaffolding to use dotnet new under the hood - put on hold, potentially post-4.0. Instead I've updated Forge temlplates to .Net Core (https://github.com/ionide/forge-templates/tree/netcoreTemplates)

[Krzysztof-Cieslak]

• Use netcore runtime of FSAC as default - done in #1114
• Remove multiple ways of workspace initialization - we will use only workspace method - done in #1114

[Krzysztof-Cieslak]

• Use new unified project parsing in FSAC - done in https://github.com/fsharp/FsAutoComplete/pull/347

[Krzysztof-Cieslak]

• Rethink the default settings - done in 6a83beb1c96d153c2777493df872aa0d477193c9

[Krzysztof-Cieslak]

• Replace project parsing notification with status bar indicator - done in 66118a5ca932224eaa46ef4bd0e79d5f45cf5fa2