Fsharp: net47 fsi is coming apart at the seams; would like dotnet fsi for VS

[reinux]

.NET 4.7 FSI has become increasingly difficult to use. Error messages (presumably) having to do with assembly target versions range from EntryPointNotFoundException to MissingMethodException to Could not load type 'System.IO.Stream' from assembly 'System.Runtime', none of which are very helpful in figuring out which assembly is out of line.

I get the sense that netstandard is already experiencing a ton of code rot, due to the fact that people are trying frantically to migrate to .net core and are cutting corners, especially wherever native libraries are concerned. Popular packages like SQLite and IdentityModel and ImageSharp all suffer .net core migration-related problems with .net 47 fsi.exe, whereas everything works fine in .NET Core -- except that I can't run it from Visual Studio.

Of course, I could raise issues on each of those packages, but I think at this point it would be more productive if we could just use dotnet fsi in Visual Studio instead, as that's where we're headed anyway.

[cartermp]

This is in long-term plans, but it's not as simple as just using dotnet fsi. The problem you're seeing - using .NET Core and .NET FX not knowing what the assemblies you're referencing are - will only be inverted by switching the FSI used in VS. We'll probably figure out a plan for this post-F# 5.

[reinux]

Could it not be an option? Or would that be too time-consuming to implement?

This may be just me, but I think even though the problem would be inverted, the trend towards .NET Core already seems to have made it way easier in most cases to deal with problems getting stuff to work in .NET Core than getting things to work with 47.

[abelbraaksma]

@reinux, in my experience, using dotnet fsi at the moment has more reference loading issues than the framework one in VS. I wonder why you see the errors you mention, maybe we can improve the errors themselves for the time being? Can you give an example?

Are you maybe trying to run .NET Core code that wouldn't be valid in Framework?

As a workaround, you can use dotnet fsi from the command line. As an extra benefit, you'll get colors ;).

[reinux]

I did have a feeling the balance might be in the other direction for a lot of people.

Here's one trying to call a .NET Standard 2.1 class library project:

System.EntryPointNotFoundException: Entry point was not found.
at System.Collections.Generic.IEnumerable1.GetEnumerator() at Data.|Regex|_|@45.GenerateNext(IEnumerable1& next)
at Microsoft.FSharp.Core.CompilerServices.GeneratedSequenceBase1.MoveNextImpl() in F:\workspace\_work\1\s\src\fsharp\FSharp.Core\seqcore.fs:line 371 at Microsoft.FSharp.Collections.SeqModule.ToList[T](IEnumerable1 source)

I was actually thinking of asking on dotnet/runtime if they could maybe provide better errors, but that would probably involve making changes to the .NET 4.7 runtime so that it can identify .NET Core/.NET Standard assemblies as such.

Although I do remember back in the win9x days, they were able to run just enough 16 bit code to print a good error message trying to run a 32 bit executable in Win3.1/DOS -- so maybe there's hope.

As an extra benefit, you'll get colors ;)

I noticed! The colors are indeed pretty. The downside is that you can't rely on compiler checks in VS anymore while you're editing fsx scripts, because it gives you errors where it shouldn't, for example trying to use SixLabors.ImageSharp:

#load @"..\.paket\load\netstandard2.1\SixLabors.ImageSharp.fsx"
#r "netstandard"
SixLabors.ImageSharp.Image.Load("...")

FixStuff.fsx(47,1): error FS1109: A reference to the type 'System.ReadOnlySpan`1' in assembly 'netstandard' was found, but the type could not be found in that assembly

[cartermp]

Could it not be an option? Or would that be too time-consuming to implement?

Quite difficult. Firstly, they have to be separate processes. So we need to manage the lifecycle of two processes, which is about 10x harder than you'd expect when doing things from VS, sadly.

Then we need to build an experience around selecting one of them, with relevant options in the options page. We then need to pick a default for launching the window with no context. We'd need to build another set of key bindings and right-click menus, or require users to always toggle which FSI they want the existing key bindings + menu items to send code to. Then it gets harder:

• We'd need to build a new FSI tool window and refactor session management (if possible) to be tool-window agnostic. Assume a full release to deal with bugs/regressions since we'll likely miss some subtle behavior(s) a few users rely on.
• When creating a brand-new F# script file, what are the default references the editor uses as context, the .NET FX references as today, or a set of .NET Core references?
• What happens if you try to execute a script in the "wrong" FSI? This matters if you're working in a larger, mixed-solution codebase.
• What FSI _should_ scripts in projects that target .NET Standard be executed against?
• How much additional memory/CPU is used by spinning up another process?
• If .NET Core FSI is a default, then what should happen with existing scripts that reference .NET Framework binaries today? We can't actually detect with 100% certainty if a script is for .NET FX or .NET Core.

It's far easier to just make the switch to .NET Core FSI only in the next major version of Visual Studio.

[reinux]

Aight, I'll make do 😄 Thanks for the detailed writeup. It's always interesting to hear about the nuanced decisions that go into language tools.

[dsyme]

It's far easier to just make the switch to .NET Core FSI only in the next major version of Visual Studio.

It would be really nice if there was a way to at least configure VS to globally use .NET Core FSI in the next update.

[dsyme]

.NET 4.7 FSI has become increasingly difficult to use. Error messages (presumably) having to do with assembly target versions range from EntryPointNotFoundException to MissingMethodException to Could not load type 'System.IO.Stream' from assembly 'System.Runtime', none of which are very helpful in figuring out which assembly is out of line.

I would like to see a catalog of known issues and when they occur