Fsharp: Visual F# Tools Announcement for April

[cartermp]

Hello folks,

This is the first of a monthly announcement I want to do on GitHub. The goal here is to more effectively communicate what's happening and how it relates to the Visual Studio schedule.

VS 2017 Update 2 will have a major update to the Visual F# Tools. This will be in about 1 month.

This will feature (roughly) all changes in the codebase up until last week. We have validated the build and are in the process of pushing that change into the correct branch of VS itself. This update is scheduled to go out roughly one month from now. There are no hard dates yet, but it will be very soon.

Some of these features will include:

• Massive performance work
• Basic autocompletion
• Clickable Go to Definition in QuickInfo
• Improvements to features across the board
• Inline Rename re-enabled
• Better semantic colorization (including mutable values)
• File previews re-enabled, including in Go to All

One change will include:

• Simplify Name codefix turned off for performance reasons

There is currently a Pull Request out to re-enable Simplify Name, as it was _actually_ disabled in master long before the VS 2017 release. We had an early cutoff point (as did everyone) for the VS 2017 release, so it shipped with that enabled and without the performance work in the language service to justify its enabling. It will be re-enabled for VS 2017 Update 3.

VS 2017 Update 3 will have another major update to the Visual F# Tools. The currently scheduled time is in July.

This will include a number of things:

• Any new features contributed by the community between now and June-ish
• Support for .NET Core projects
• Support for .NET Core 2.0 and .NET Standard 2.0
• Some new F# 4.2 language features, if they're finished by then

You can track the work of .NET Core support in VS here: https://github.com/dotnet/project-system/issues?q=is%3Aopen+is%3Aissue+label%3AArea-F%23

Please do note that the initial support is already checked in, and if you want to be on the bleeding edge and/or help out with that work, please clone the dotnet/project-system repository and work with the team who owns that code. This will eventually be the place where _all_ F# code runs in, but for the sake of the schedule, this is being explicitly scoped to .NET Core support for now. We'll be migrating over fully later this year.

Thanks!

[panesofglass]

@cartermp any word on whether generative type providers will be available as of .NET Core/Standard 2.0? Also, is the .NET Core support referenced above ready to test existing erasing type providers? (Or am I missing the point of this post?)

[cartermp]

@panesofglass No satisfactory answers to report, I'm afraid.

Generative TPs will be cut from .NET Core/.NET Standard 2.0. They currently take a dependency on System.Reflection.Emit, which is not going to be available at that time. The team who owns that library will be taking a look at how to bring it up later this year. It's a high priority for them post-2.0 release. Unless there's an effort to rewrite Type Providers all-up, Generative TPs are tied to System.Reflection.Emit's availability.

In terms of testing erasing TPs, right now the answer is no. There isn't anything available for people to test with F# on .NET Core/Standard 2.0 right now. The breaking issue with Generative TPs is that they took a dependency on a Type() constructor which was made private in .NET Standard 1.0. That constructor change is reverted. I don't have a timeline on when code here will be available to test. @KevinRansom would have a better idea.

[zpodlovics]

@panesofglass Take a look at my comment about Managed.Reflection (it runs on .NET Core 1.0 and .NET Framework 4.6 and up) as fully managed System.Reflection.Emit replacement in https://github.com/Microsoft/visualfsharp/issues/2406#issuecomment-288205314

[dsyme]

Generative TPs will be cut from .NET Core/.NET Standard 2.0. They currently take a dependency on System.Reflection.Emit, ...

Generative TPs just need any code generator - our tests certainly use S.R.E, but any old binary generator will do (ILASM, CSC, FSC, Managed.Reflection, Mono.Cecil, whatever).

So our ability to test generative TPs extensively may be imparied - but we should be able to have the mechanisms technically speaking, unless we hit some unknown blocker

[dsyme]

Closing old discussion