New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

July/August Update for F# and Visual F# Tools #3507

Closed
cartermp opened this Issue Aug 26, 2017 · 15 comments

Comments

Projects
None yet
10 participants
@cartermp
Collaborator

cartermp commented Aug 26, 2017

Hello folks,

It's been a busy couple of months! The following has shipped since my last update:

  • F# support for .NET Core 2.0 and .NET Standard 2.0.
  • Visual Studio 2017 version 15.3, with multiple updates, including better responsiveness in the language service.
  • Improvements to the F# documentation to improve SEO, both in metadata and the way things were worded, and an updated Get Started section.

Additionally, the F# community has contributed significant improvements in multiple areas:

  • Added configuration for in-memory cross-project references and the project cache size. This is for folks who have large F# solutions and wish to tweak the behavior of the tooling. None of these options are a silver bullet, but they should unblock those who have had large troubles adopting VS 2017 due to the nature of their solutions.
  • Go to C# symbols from F#. This one is pretty straightforward 😄.
  • Auto-indentation (and smart de-indentation coming soon) in the editor.
  • Deterministic compilation with the --deterministic flag.
  • Wrapped XML documentation in QuickInfo.
  • Support for Blue Theme (high contrast)
  • Performance improvements and bug fixes in the compiler, tools, and FSharp.Core

A big thank you to everyone involved here, and also to those who have been testing out F# support on .NET Core 2.0 as it moved through various preview support phases, catching bugs early on that we were able to fix in a timely fashion.

We're really excited for .NET Core 2.0, and we're happy to see the F# OSS ecosystem already adopting .NET Core. It's exciting looking back and how much has been accomplished in so short a time. A little over a year ago, the .NET Core runtime and libraries had just shipped a 1.0 release, and the SDK and CLI tooling had continued to remain in preview all the way until March of this year. That tooling, with the recent 2.0 release, is finally in a good enough state to support larger applications and existing code. I'm really happy that projects such as Fable-Suave Scaffold have been able to upgrade so rapidly, and I'm also happy to say that we will be validating this project with our manual testers on a regular cadence. In other words, Microsoft will be validating that Fable and Suave work nicely together on .NET Core 2.0+.

We still have plenty of remaining work to do with .NET Core: Type Providers, Code Quotations, and full F# Interactive support are not there yet. The tooling support in Visual Studio is still in-progress.
The lightweight, cross-platform acquisition story with Ionide still requires work in its dependent projects. Our own infrastructure still doesn't use the .NET Core SDK. Azure Functions doesn't support 2.0-based compiled function apps yet. Azure Notebooks still runs Mono in the background.
But enough of F# and its ecosystem is capable of running on .NET Core that you can legitimately run production applications on it today. I'm very happy about this, and I'm positive that in the next year or two, the majority of F# projects in the world will run, in some part, on .NET Core.

So, what's next?

Step one: Get the Visual Studio support for F# and .NET Core SDK-based projects in a good place. We are targeting Visual Studio 2017 version 15.4 Preview 3 as the release where preview support will first be available. We're currently targeting Visual Studio 2017 version 15.5 as the release where it is fully supported.

From there, we haven't really decided the priority of the following items yet:

  • Further performance investigations to see what we can do about F# performance in Visual Studio, particularly around solution load times.
  • Get our build to use the .NET Core SDK.
  • Do the work to allow Erasing Type Providers to work on .NET Core without the current workaround (#3303).
  • Implement an extensibility point in F# Interactive, backed by a proper design, to allow extended #r syntax ideas to become a reality into fruition, and thus unblock F# interactive from full support on .NET Core.
  • Work with other .NET teams and do necessary work to unblock full Code Quotations and Generative Type Providers from running on .NET Core.
  • Work with the Azure Functions and Azure Notebooks teams to ensure that they can adopt .NET Core 2.0 for their F# support.
  • Work towards F# 4.2.
  • Work with the Xamarin MDoc team to fully support F# language features, thus allowing the FSharp.Core API reference to migrate from MSDN to docs.microsoft.com.
  • Further F# evangelism on the .NET Blog and Channel 9.
  • The migration of F# into the CPS-based .NET project system, thus allowing us to deprecate our own bespoke and wildly complex project system.

The scope of the above list is beyond just that of .NET Core, and encompasses a long tail of work across the multiple product areas. Progress there will be iterative in nature, and it will take time to accomplish them. But given how fast F# has evolved and improved in the past year, I'm confident that it will end up happening a lot faster than we can really anticipate.

Thanks to everyone who's been contributing, filing issues, helping grow F#, and push it in places it's never been before. I'm already looking forward to posting the next update to this repo, which will undoubtedly be filled with fun features and thank-you's to the community!

@xperiandri

This comment has been minimized.

Show comment
Hide comment
@xperiandri

xperiandri Aug 28, 2017

F# support for .NET Core 2.0 and .NET Standard 2.0.

@forki, does it mean that in ASP.NET Core 2.0 project Intellisens and light bulb must work?

xperiandri commented Aug 28, 2017

F# support for .NET Core 2.0 and .NET Standard 2.0.

@forki, does it mean that in ASP.NET Core 2.0 project Intellisens and light bulb must work?

@eriawan

This comment has been minimized.

Show comment
Hide comment
@eriawan

eriawan Aug 28, 2017

Contributor

@cartermp

CMIIW. But I don't see any updates on .NET Native support for F#.
Is this .NET Native support still being worked?

Contributor

eriawan commented Aug 28, 2017

@cartermp

CMIIW. But I don't see any updates on .NET Native support for F#.
Is this .NET Native support still being worked?

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Aug 28, 2017

Contributor
Contributor

forki commented Aug 28, 2017

@charlesroddie

This comment has been minimized.

Show comment
Hide comment
@charlesroddie

charlesroddie Aug 28, 2017

You are all working hard. But after step 1, please prioritize .NET Native.

charlesroddie commented Aug 28, 2017

You are all working hard. But after step 1, please prioritize .NET Native.

@matthid

This comment has been minimized.

Show comment
Hide comment
@matthid

matthid Aug 28, 2017

Contributor

@charlesroddie I don't get why all always point their finger to the F# team. It's a .NET Native bug that they didn't support tail calls from day one. If we want to F# to succeed we can't assume that the F# team will do everything, other teams at least need to follow specs...

Contributor

matthid commented Aug 28, 2017

@charlesroddie I don't get why all always point their finger to the F# team. It's a .NET Native bug that they didn't support tail calls from day one. If we want to F# to succeed we can't assume that the F# team will do everything, other teams at least need to follow specs...

@matthid

This comment has been minimized.

Show comment
Hide comment
@matthid

matthid Aug 28, 2017

Contributor

I think what I'm trying to say is this: .NET Native support is probably independent from the above (I think).

Contributor

matthid commented Aug 28, 2017

I think what I'm trying to say is this: .NET Native support is probably independent from the above (I think).

@charlesroddie

This comment has been minimized.

Show comment
Hide comment
@charlesroddie

charlesroddie Aug 28, 2017

@matthid It's not a matter of blame. If the F# team does not help the .NET native team to diagnose any problems and suggest solutions there will continue to be no progress. Lack of tailcall support is irrelevant as it is not a blocking issue.

charlesroddie commented Aug 28, 2017

@matthid It's not a matter of blame. If the F# team does not help the .NET native team to diagnose any problems and suggest solutions there will continue to be no progress. Lack of tailcall support is irrelevant as it is not a blocking issue.

@a688

This comment has been minimized.

Show comment
Hide comment
@a688

a688 Aug 30, 2017

@charlesroddie If you read @cartermp 's post here #1096 (comment)

you can see that UWP/.NET native is NOT a priority for Microsoft at all. If you want a store app, just use desktop bridge and WPF. Microsoft themselves, through their actions, clearly don't care about supporting their own Mobile OS, seriously developing UWP apps (that aren't desktop bridge'ed), or making sure UWP is the (only) way forward (seriously how many different, mostly incompatible, UI frameworks does MS really need?). If you just want .NET native just for the speed then it may never happen.

a688 commented Aug 30, 2017

@charlesroddie If you read @cartermp 's post here #1096 (comment)

you can see that UWP/.NET native is NOT a priority for Microsoft at all. If you want a store app, just use desktop bridge and WPF. Microsoft themselves, through their actions, clearly don't care about supporting their own Mobile OS, seriously developing UWP apps (that aren't desktop bridge'ed), or making sure UWP is the (only) way forward (seriously how many different, mostly incompatible, UI frameworks does MS really need?). If you just want .NET native just for the speed then it may never happen.

@idg10

This comment has been minimized.

Show comment
Hide comment
@idg10

idg10 Sep 6, 2017

The feature I'm most eagerly hoping for is the ability to use <PackageReference> for NuGet package references, both directly from an F# project (ideally from projects targeting either .NET Core or .NET Framework) but also as transient dependencies picked up automatically from project references. (E.g., if my F# project references a C# library project that expresses its dependencies with <PackageReference> then I shouldn't need my F# project also to explicitly reference all the packages the C# project depends on.) In other words, I'd like to be able to use MSBuild-v15-style .fsproj files in Visual Studio 2017 in exactly the same way I can use this new style of .csproj today.

I think that's what's implied by this:

Get the Visual Studio support for F# and .NET Core SDK-based projects in a good place. We are targeting Visual Studio 2017 version 15.4 Preview 3 as the release where preview support will first be available.

But am I being too optimistic about what you're planning to deliver here?

Will this start to appear in the nightly builds any earlier? Or does this work depend on changes elsewhere in Visual Studio that won't be available until 15.4?

idg10 commented Sep 6, 2017

The feature I'm most eagerly hoping for is the ability to use <PackageReference> for NuGet package references, both directly from an F# project (ideally from projects targeting either .NET Core or .NET Framework) but also as transient dependencies picked up automatically from project references. (E.g., if my F# project references a C# library project that expresses its dependencies with <PackageReference> then I shouldn't need my F# project also to explicitly reference all the packages the C# project depends on.) In other words, I'd like to be able to use MSBuild-v15-style .fsproj files in Visual Studio 2017 in exactly the same way I can use this new style of .csproj today.

I think that's what's implied by this:

Get the Visual Studio support for F# and .NET Core SDK-based projects in a good place. We are targeting Visual Studio 2017 version 15.4 Preview 3 as the release where preview support will first be available.

But am I being too optimistic about what you're planning to deliver here?

Will this start to appear in the nightly builds any earlier? Or does this work depend on changes elsewhere in Visual Studio that won't be available until 15.4?

@cartermp

This comment has been minimized.

Show comment
Hide comment
@cartermp

cartermp Sep 6, 2017

Collaborator

@idg10 .NET Core SDK-based projects are the ones which use MSBuild 15, the smaller project files, and the <PackageReference> construct.

Will this start to appear in the nightly builds any earlier? Or does this work depend on changes elsewhere in Visual Studio that won't be available until 15.4?

It is not likely that this will appear in the nightly builds or earlier.

Collaborator

cartermp commented Sep 6, 2017

@idg10 .NET Core SDK-based projects are the ones which use MSBuild 15, the smaller project files, and the <PackageReference> construct.

Will this start to appear in the nightly builds any earlier? Or does this work depend on changes elsewhere in Visual Studio that won't be available until 15.4?

It is not likely that this will appear in the nightly builds or earlier.

@KevinRansom

This comment has been minimized.

Show comment
Hide comment
@KevinRansom

KevinRansom Sep 6, 2017

Contributor

@idg10
The reason it will not appear in the nightly is because it requires changes to the project-system code that ships separately.

Contributor

KevinRansom commented Sep 6, 2017

@idg10
The reason it will not appear in the nightly is because it requires changes to the project-system code that ships separately.

@idg10

This comment has been minimized.

Show comment
Hide comment
@idg10

idg10 Sep 8, 2017

it requires changes to the project-system code that ships separately

OK - that's what I suspected, just wanted to check there wasn't something I could be testing sooner.

I have one question about this in @cartermp's reply:

.NET Core SDK-based projects are the ones which use MSBuild 15, the smaller project files, and the construct

Are you intending to support targetting the full .NET Framework with this style of project? You can do this today in C# .NET Core SDK-based projects (although I don't think there's any UI for it - you have to open up the .csproj and set the <TargetFramework>).

The reason I care about this is that I'm not yet even sure if I can migrate my system to .NET Core - we depend on a large number of NuGet packages, and I don't yet know how many of these can run on Core. So my plan is to gradually migrate the various elements of my system over to .NET Standard 2.0, starting with 'leaf' libraries, and gradually working up the stack. (It uses a mixture of C# and F# right now.) But this depends on the 'root' projects (currently various F# web jobs and C# web apps) being able to target, say. NET 4.7.1 but consume .NET Standard 2.0.

(Frankly, I'm not even especially excited about moving over to .NET Core. It seems like we're being pushed that way - at one point the plan was that ASP.NET Core 2 wouldn't run on regular .NET. Thankfully they stepped back from that particular ledge, but it reveals a mindset in which full .NET is considered 'deprecated'. And we're starting to see Core-only things e.g. Azure Service Fabric apparently not offering full .NET. So I'm reluctantly trying to work out what it will take for our code to run there.)

I can't begin this process today unless I abandon Visual Studio because non-Core-SDK F# projects can't consume .NET Standard library projects, and Core SDK F# projects don't open properly in Visual Studio. But once these projects do work in VS, the ability to target full .NET is important to me because I don't want to have to migrate my entire project in one go, and I'm not even sure if I can; it if turns out I'm waiting on some external components to add Core support, I don't want to be prevented from using <PackageReference>.

idg10 commented Sep 8, 2017

it requires changes to the project-system code that ships separately

OK - that's what I suspected, just wanted to check there wasn't something I could be testing sooner.

I have one question about this in @cartermp's reply:

.NET Core SDK-based projects are the ones which use MSBuild 15, the smaller project files, and the construct

Are you intending to support targetting the full .NET Framework with this style of project? You can do this today in C# .NET Core SDK-based projects (although I don't think there's any UI for it - you have to open up the .csproj and set the <TargetFramework>).

The reason I care about this is that I'm not yet even sure if I can migrate my system to .NET Core - we depend on a large number of NuGet packages, and I don't yet know how many of these can run on Core. So my plan is to gradually migrate the various elements of my system over to .NET Standard 2.0, starting with 'leaf' libraries, and gradually working up the stack. (It uses a mixture of C# and F# right now.) But this depends on the 'root' projects (currently various F# web jobs and C# web apps) being able to target, say. NET 4.7.1 but consume .NET Standard 2.0.

(Frankly, I'm not even especially excited about moving over to .NET Core. It seems like we're being pushed that way - at one point the plan was that ASP.NET Core 2 wouldn't run on regular .NET. Thankfully they stepped back from that particular ledge, but it reveals a mindset in which full .NET is considered 'deprecated'. And we're starting to see Core-only things e.g. Azure Service Fabric apparently not offering full .NET. So I'm reluctantly trying to work out what it will take for our code to run there.)

I can't begin this process today unless I abandon Visual Studio because non-Core-SDK F# projects can't consume .NET Standard library projects, and Core SDK F# projects don't open properly in Visual Studio. But once these projects do work in VS, the ability to target full .NET is important to me because I don't want to have to migrate my entire project in one go, and I'm not even sure if I can; it if turns out I'm waiting on some external components to add Core support, I don't want to be prevented from using <PackageReference>.

@dsyme

This comment has been minimized.

Show comment
Hide comment
@dsyme

dsyme Sep 8, 2017

Contributor

Are you intending to support targetting the full .NET Framework with this style of project?

This is already supported, and I believe many people are using it.

Contributor

dsyme commented Sep 8, 2017

Are you intending to support targetting the full .NET Framework with this style of project?

This is already supported, and I believe many people are using it.

@cartermp

This comment has been minimized.

Show comment
Hide comment
@cartermp

cartermp Sep 8, 2017

Collaborator

It is currently not fully supported. You can open those projects today, but not create them (we turned off templates).

.NET Core SDK-based projects allow you to target .NET Framework, but it still uses all the pieces that .NET Core projects do from Visual Studio's perspective: .NET Core SDK and CPS. It is here where F# still lacks full support.

Collaborator

cartermp commented Sep 8, 2017

It is currently not fully supported. You can open those projects today, but not create them (we turned off templates).

.NET Core SDK-based projects allow you to target .NET Framework, but it still uses all the pieces that .NET Core projects do from Visual Studio's perspective: .NET Core SDK and CPS. It is here where F# still lacks full support.

@cartermp

This comment has been minimized.

Show comment
Hide comment
@cartermp

cartermp Oct 7, 2017

Collaborator

Closing old discussion

Collaborator

cartermp commented Oct 7, 2017

Closing old discussion

@cartermp cartermp closed this Oct 7, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment