Visual F# Tools Announcement for May

[cartermp]

Hey folks,

Here's an update on stuff for the month of May. Sorry for not doing this earlier. Very very busy ship schedule and the //Build conference has been sucking the air out of the room for me

What's new?

Community:

• Many, many changes from the community inserted in Visual Studio 2017 Update 2
• Even more changes have been inserted into the RTM branch of our tools, and will appear in Visual Studio 2017 Update 3 Preview 2.
• The list of amazing features done by the community is huge and growing. Some of the coolest of them include:
  • Folder support
  • Settings support
  • Autocompletion with symbols defined in assemblies tucked behind a namespace
  • Add Reference to code fix
  • Clickable QuickInfo to Go to Definition on any symbol in the window
  • A WIP codelens-like feature which shows Type Signatures you can click on to Go to Definition
• Many, many bug fixes and performance improvements
• In general, the community has moved the VS 2017 Updates milestone from 0% to 67% complete in the span of 3 months

Microsoft:

• Many internal bug fixes in reaction to Visual Studio and Roslyn platform changes
• Fixed an issue where we broke XML colorization globally in VS
• Addressed many severe issues in our internal build which were previously unknown to us until a PR to enable settings by @cloudRoutine exposed them, resulting in a broken internal build for a few weeks
• Moved F# into the .NET Core SDK as in-band so that F# is first-class for .NET Core and is distributed by default there
• In the process of moving F# into the .NET Core SDK, fixed various issues with multitargeting with the .NET Core SDK
• Implemented support for F# in the new project system, thus enabling F# to open .NET Core projects in Visual Studio
• Working with the team which packages sources in the RedHat distribution of .NET Core so that F# can be fully built from source for .NET Core on *nix machines
• Finished documentation for F# 4.1 and awaiting final review
• Wrote Getting Started material for F# on VS for Mac
• Initiated communications with JetBrains to coordinate any changes to the F# Compiler Service, specifically so that Repo alignment - How to enable xplat workflow for easy contribution #2854 does not end up biting them in ways we didn't anticipate
• Began accessibility work for semantic colors to ensure that F# meets the accessibility bar

So what about those dates?

Just to reduce typing on my part, this is the rubric to follow:

15.2 ---> Visual Studio 2017 Update 2 (shipped)
Preview 1 ---> Visual Studio 2017 Update 3 Preview 1 (Shipped)
Preview 2 ---> Visual Studio 2017 Update 3 Preview 2
Preview 3 ---> Visual Studio 2017 Update 3 Preview 3
15.3 ---> Visual Studio 2017 Update 3
15.4 ---> Visual Studio 2017 Update 4

15.2 has shipped. It includes significant feature work from the community. Preview 1 has also shipped, but the bits are the same as 15.2. We are inserting an equally large update of features and bug fixes into Preview 2. .NET Core 2.0 support and support for loading and building .NET Core projects into Visual Studio will also be available in Preview 2. Preview 3 is for large bug fixes only, so for all intents and purposes, the features which go into Preview 2 will be the same in 15.3.

Wew. Let's break that down a bit.

15.2 and Preview 1

Preview 1 shipped at the same exact time as 15.2. Basically, C# and .NET were granted no insertion for 15.2, but were granted one for Preview 1. So they did that, and there are multiple new features in that space for Preview 1. We were granted an insertion for both 15.2 and Preview 1, so we inserted the stable bits we had at that time. Numerous issues cropped up, but because they weren't severe (severe = basically destroying a visual studio installation), they could not get fixed. It's a preview release, anyways, so we aren't too concerned. Multiple other teams across DevDiv could not get features or bug fixes in at that date.

Preview 2

Update: 5/31/2017: All changes initially slated for Preview 2 have been moved for Preview 3. There's a lot of working coming in for us and others, and with the extremely tight schedule, we missed our window for an insertion. Please do keep in mind that Previews are not supported releases.

Preview 3

Preview 3 is upcoming. This is the preview release where we will insert many features and bug fixes into Visual Studio. This will include some of the newer changes to autocomplete and clickable QuickInfo, and all settings changes to tune different features. It will also include .NET Core support in Visual Studio, and the first supported bits to target .NET Core 2.0 and .NET Standard 2.0. We will also be working with the Azure Functions team to make sure they pick up our bits when they make the full transition over to .NET Standard.

15.3

This will be the third update to Visual Studio 2017. .NET Core 2.0 RTW may be shipped at this time. It's equivalent to what used to be called Update 1, so there will be significant new features across the board.

15.4

This will be a smaller update, similar to 15.2. We will likely be granted an insertion here, so any features implemented between now and then will likely be inserted at this time.

What about Type Providers and .NET Core?

In theory, Erasing Type Providers will work on .NET Core 2.0 without any changes. @dsyme and @KevinRansom will be looking at this once the bits for .NET Core 2.0 and F# are stable enough. Generative Type Providers are cut for .NET Core right now. They take a dependency on System.Reflection.Emit, which has been cut for .NET Core 2.0 and .NET Standard 2.0. It's a high priority for the team who owns that library to make it available, though, and we help motivate that work. They will not begin until after .NET Core 2.0 ships, though.

What about F# Interactive and .NET Core?

We are cutting F# Interactive for the 15.3 and .NET Core 2.0 release. There are simply too many issues which we cannot deal with at this time. We share most of these issues with C# Interactive too (which is also effectively cut), so we'll be working with @tmat and @richlander to come up with a general solution for shipping FSI and CSI in .NET Core distributions in addition to coming up with a solution for dealing with the reference model for .NET Core and .NET Standard. Once that is implemented, it will enable work to do things like #r "paket:..." so that you can reference packages directly.

[saul]

Great progress 😄 Looking forward to 15.3 general availability.

With regards to:

Implemented support for F# in the new project system, thus enabling F# to open .NET Core projects in Visual Studio

Where is this? I thought the F# support in dotnet/project-system was really, really basic right now? Or is there something being developed internally that hasn't been made public yet?

[dsyme]

Where is this? I thought the F# support in dotnet/project-system was really, really basic right now? Or is there something being developed internally that hasn't been made public yet?

cc @srivatsn, also see current issues https://github.com/dotnet/project-system/issues?q=is%3Aopen+is%3Aissue+label%3AArea-F%23

[saul]

@dsyme but dotnet/project-system#1896 is now on the 16.0 milestone - no longer being developed for 15.3. We can't move to the new project system without node ordering 😞

[dsyme]

@saul Good point - will leave it up to @srivatsn and @cartermp to comment on schedule

[srivatsn]

@saul in dotnet/project-system#1875 there seems to be a discussion about adding a new node instead of ordering. I moved ordering out because of that.

[saul]

@srivatsn I think you've misunderstood - the new node would still have ordering in its child nodes. The ordering is imperative to F# whether we display compile order in its own node or not.

[srivatsn]

If it is a custom node then I think we can already order that - it's only the main tree that cannot be ordered today.

[saul]

It's all of the nodes within the custom node that need ordering - I thought ordering nodes at all was not possible with the current framework?

[srivatsn]

There are two ways of drawing nodes - IVsHierarchy and graph nodes. I believe we can order with graph nodes - I'll double check though.

[saul]

Thanks @srivatsn - apologies to Phillip for completely derailing the conversation on this issue. Do you mind replying to me on dotnet/project-system#1875, Srivatsn?

[onionhammer]

We are cutting F# Interactive for the 15.3 and .NET Core 2.0 release. There are simply too many issues which we cannot deal with at this time. We share most of these issues with C# Interactive too (which is also effectively cut), so we'll be working with @tmat and @richlander to come up with a general solution for shipping FSI and CSI in .NET Core distributions in addition to coming up with a solution for dealing with the reference model for .NET Core and .NET Standard. Once that is implemented, it will enable work to do things like #r "paket:..." so that you can reference packages directly.

I hope this means F# interactive in Visual Studio catches up to F# interactive in Visual Studio for Mac, too! Coloring, tab completion, etc are awesome. Hell, even FSI in the command line has these. F# Interactive in Visual Studio is lagging so far behind right now.

[vasily-kirichenko]

@onionhammer If you don't implement these FSI features, they won't become real.

[onionhammer]

@vasily-kirichenko I'm a consumer of FSI features, not a producer. Separation of concerns.

[KevinRansom]

@onionhammer
We are an open source project, and so can certainly accept pull requests implementing these features. You might find it quite interesting to become a producer of such features.

Kevin

[cartermp]

I have updated this announcement to reflect current changes as of today. Unfortunately, we will not be able to get an insertion into Preview 2 of 15.3. It's a wild schedule right now, so this sort of churn is expected to happen at some point or another.

[forki]

What about promised new project system? Can't see it in the announcements?

[cartermp]

It will also include .NET Core support in Visual Studio

This is the project system support. Since the CPS-based project system is only for .NET Core at the moment, we'll have the same story as C#: new project system support as the mechanism for .NET Core support in VS.

[forki]

Ok this is super confusing. You can't build with the project system for let's say net452?

[0x53A]

Ok this is super confusing. You can't build with the project system for let's say net452?

That's also what I would like to know.

I was under the impression before that new-proj-system == new-sdk, regardless of target.

What happens if I create a new-sdk core project, and just change the TargetFramework to net461?

[cartermp]

Yes, you can. But the new project system doesn't support opening existing .NET Framework projects. So the bulk of code out there can't utilize it unless they port over to the new SDK. It will eventually replace the older project systems for C#, VB, and F#, but that's a longer tail effort.

[forki]

ok so it's nothing to do with .NET core. thanks

[0x53A]

So in theory, with VS15.3, I can move all my projects (C# + F#) to the new sdk, and still target net461? Sounds good.

[cartermp]

In theory, assuming you didn't depend on behavior in the old project system which isn't present in the new one, yes. There isn't a tool for migration or anything, though.

[0x53A]

Is there something I can already test? As I read it, it will only be available in Preview3, and by then it will probably be too late to fix any bugs anway.

[forki]

@0x53A no this time it will work out just fine ;-)

[0x53A]

Maybe in vs16

[cartermp]

@0x53A No, nothing to test at the moment.

[cartermp]

As of today, the ship date for Update 3 has also moved back. No definitive date yet. This statement:

15.3 ---> Visual Studio 2017 Update 3 (Mid-July)

Is no longer true. Further releases are also affected by this. Again, nothing definitive about this.

What that means for us is we have more time. I'll make another announcement on this repo once we have more definitive information.

[0x53A]

@cartermp Since there is nothing public to test, I will just have to annoy you. =)

1. Will cross-referencing between old-sdk and new-sdk work? (For my use-case it wouldn't be breaking if no, I can migrate all projects in the solution.)
2. Can you please verify if type providers work with the new project-system projects targeting full-framework?
   This issue from the previous sdk suggests that it didn't: Support FSharp.Data on .Net Core netcorecli-fsc#16 (comment)

[cartermp]

@0x53A We're still in the process of understanding what we can reasonably get done. More obvious things like load/build/debug/IDE features/etc. will work (e.g., language service lights up and lightbulbs appear as in the old project system), but other scenarios are still unknown to us.

1. I would not assume that cross-SDK references will work, but it's something we'll validate. Especially when 2.0 ships, it's going to be in your best interest to migrate completely over to 2.0 regardless of if you're in VS or not.
2. Type Providers running on .NET Framework in the new project system is one of the things we're evaluating.

We're still in the process of shuffling around what we can reasonably do by 15.3 given the increased time.

[cartermp]

Closing old discussion.

[NullVoxPopuli]

has there been any progress on dotnetcore2 typeproviders?
found: fsprojects/FSharp.Data.TypeProviders#16

[baronfel]

Yes! Check out this tweet thread from @dsyme:
https://twitter.com/dsyme/status/981799285925842945

The short form is that if you use the configurations called out in that tweet thread, then FSharp.Data will work. Other type providers need to be updated to work as well, so please raise issues on the appropriate repos and/or submit a PR yourself.

[NullVoxPopuli]

YAY!

That's very recent :-)