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

2017 Status and Roadmap for F# and the Visual F# Tools #2400

Closed
cartermp opened this Issue Feb 9, 2017 · 50 comments

Comments

Projects
None yet
@cartermp
Contributor

cartermp commented Feb 9, 2017

Current Status of F# and the Visual F# Tools per VS2017 RTM

  • F# 4.1 is feature complete
    • Multiple new features, including struct representation of types, a new Result type, and other areas that are “nip and tuck” in nature
    • Multiple bug fixes
    • One by-design breaking change for C#-style Extension Methods
    • One known regression (#2373)
    • One known bug in multi-case Struct DUs (#1678)
  • .NET Framework compiler in good shape
  • .NET Framework FSI in good shape
  • .NET Core compiler in RC
    • Type Providers and Codegen from Quotations are not supported due to changes made in reflection APIs for .NET Core. These will be in .NET Core 2.0+ timeframe.
  • .NET Core FSI works as a simple REPL
    • However, it does not support the .NET Core references model and thus does not support #r
  • Visual F# Tools in Visual Studio 2017 is sitting atop Roslyn Workspaces with many new features thanks to the OSS Community
    • It's much easier to add new features to the tooling now
    • However, there are numerous regressions that are going to be fixed
  • Visual FSI window in Visual Studio 2017 is in good shape
  • Debugging is in good shape, with multiple areas of improvement
    • Support for Portable PDBs and Desktop PDBs on .NET Framework
    • Support for Portable PDBs on .NET Core
    • Support for Embedded Portable PDBs on .NET Framework and .NET Core
    • Support for embedded source code with Portable PDBs on .NET Framework and .NET Core
    • Points of significance:
      • Still no Expression Evaluator (EE) for F#, so that means many debugging features are still unavailable as they always have been
      • Regression when debugging F# Lists: the .Items property is not invoked by the Roslyn EE used in Visual Studio
      • No other regressions that we can find
      • Legacy EE will be going away
  • The Visual F# Tools project system does not support F# on .NET Core
    • The new .fsproj file does not load in VS
    • No project system support for package load, cross-platform build, or publish
    • No .NET Core templates in-box
    • This means you can create something with the .NET CLI and have it fail to load in Visual Studio
  • Lightweight Solution Load is not compatible with F# for VS 2017 release.
    • Build/Rebuild/Clean do not work
    • Text searching through any F# projects do not work either.

Immediate Roadmap for 2017

  1. Bug fixes

    • Fixing tooling regressions in VS 2017 tooling
    • Fixing serious bugs in new features in VS 2017
    • Fixing serious bugs in the compiler
  2. Stability

    • It’s crucially important that we get our tooling stability up to spec. Many new features were introduced, but we didn’t increase our test coverage by much.
    • There is currently a bug on our side which prevents the Connected Services node in VS 2017 from working with F# projects.
    • Performance and memory-consumption issues
      • There were regressions here introduced in VS 2017 compared with VS 2015. It will be an ongoing battle to improve this, but we’ve already seen big improvements from Don just recently.
    • Build/Rebuild/Clean and Text Search do not work if Lightweight Solution Load is turned on. We’ll work with the team that owns this to get this fixed.
  3. Migrate the OSS Build to the latest .NET CLI and MSBuild and use the Multilingual App Toolkit (MAT) for localization builds

    • Migrating OSS Build to latest .NET CLI and MSBuild is necessary for .NET Core 2.0 support, which is in turn necessary to get Type Providers, Quotation support, and #r support in F# for .NET Core
    • Using the MAT will also bring down our internal build times for signed binaries tremendously
  4. Support generating signed VSIXs of the latest master build, pushed directly to MyGet

    • This will enable people to get on a “Fast track” for F# tooling in VS 2017, test out brand-new features, and provide feedback early on
    • The artifacts produced will come with the assumption that people know they won’t be as well-tested and may introduce regressions
  5. Project System support for .NET Core and .NET Standard projects in F#

    • Ability to load MSBuild 15-based .fsproj projects
    • Add gestures for cross-platform builds, publish, and adding package references
    • Consideration: Roslyn Project System
      • Add F# support to the new project system that C# and VB use for .NET Core/Standard projects
      • Remove our own project system entirely, making us “first-class” in that regard
      • This is pending an investigation into the work involved
  6. Full FSI support on .NET Core 2.0

    • Properly handle the model for how .dlls are laid out on disk with .NET Core, thus fixing #r
    • Establish a good working model for how to do the above
    • Prompt to re-load an FSI session when #r’ing an assembly that targets a higher target than what FSI was launched with?
      • Error message asking user to re-load FSI manually?
      • Try to re-target and re-reference everything on the fly?
  7. Full support for F# on .NET Core 2.0 and .NET Standard 2.0

    • Type Providers and Code Quotations
    • This also takes a dependency on RefEmit. We’ll need to investigate this further, since it’s currently not on the .NET Core 2.0 roadmap
  8. Build a Contract .dll between Roslyn and F# to remove our use of InternalsVisibleTo

    • This will allow Roslyn to determine when they break us if they make any breaking changes to their APIs
    • This will be a big improvement over the current situation, where we must manually check this
  9. OSS Engineering Efficiency and Build needs some improvements

    • The .NET CLI does not use project.json anymore, but our OSS Build still relies on that
    • The .NET CLI uses MSBuild 15 and PackageReferences, which we need to support
    • Open Source Localization is needed to simplify our localization process and more easy leverage the OSS community
      • Using the Multilingual App Toolkit is a way to improve our internal process and reduce build times

In accordance with the above, what follows is where we expect work will come from. In the case of the OSS Community, while we don't assume work will be done for us, we anticipate continuing to receive high-quality contributions which we will gladly accept.

@KevinRansom

  • VS support for loading .NET Core 1.x projects in Visual Studio
    • This is an issue being addressed in the short-term
  • F# Compiler support for .NET Core 2.0
  • FSI support for .NET Core 2.0
  • Type Provider and Code Quotations support for .NET Standard 2.0
  • System.ValueTuple work to deal with its migration to mscorlib in .NET Framework 4.6.3
  • Helping with concrete work in evolving F# 4.2
  • Bug fixes in the compiler, PDBs, debugging, and platform support

@brettfo

  • Bug fixes in the VS Tooling
    • Addressing regressions and serious bugs in new features
    • Connected Services Node bug and other issues with VS features
  • Addressing the OSS Build
  • Getting our internal builds to a place where we can publish signed VSIXs for people to use
  • Addressing Localization
    • Using the Multilingual App Toolkit to reduce build times and remove our internal clone of this repo
    • Improve OSS Localization
  • Investigating F# support on the Roslyn Project system, and acting on that if it's deemed reasonable
  • Support the community

@cartermp

  • Blog post with a focus on OSS attribution for F# 4.1 and the Visual F# Tools in VS 2017
  • Outreach to internal teams to address issues that affect us
  • Support the community
  • Low-impact bug fixes, if possible

@dsyme and the F# OSS Community

  • F# 4.2 evolution
  • Additional IDE features and improvements
  • Performance improvements
  • Bug fixes (note: this does not mean that we are punting bug fixes to the community. It means we will accept any bug fixes from the community)

Roslyn Team

  • Helping us and the OSS community better understand Roslyn when working on features
  • Engaging with and helping unblock the OSS community
@GiorgioG

This comment has been minimized.

Show comment
Hide comment
@GiorgioG

GiorgioG Feb 9, 2017

I'm surprised the project system support for .NET Core / MSBuild 15-based .fsproj projects is so far down on the list. Given that .NET Core presents an opportunity to use F# (in part at least) for greenfield/rewrite projects, I would have thought a higher priority would have been given to this since it could help increase adoption numbers.

GiorgioG commented Feb 9, 2017

I'm surprised the project system support for .NET Core / MSBuild 15-based .fsproj projects is so far down on the list. Given that .NET Core presents an opportunity to use F# (in part at least) for greenfield/rewrite projects, I would have thought a higher priority would have been given to this since it could help increase adoption numbers.

@cartermp

This comment has been minimized.

Show comment
Hide comment
@cartermp

cartermp Feb 9, 2017

Contributor

@GiorgioG Supporting .NET Core and MSBuild 15-based projects is the top item for @KevinRansom. I wouldn't interpret numbers in the list as an overall priority.

Contributor

cartermp commented Feb 9, 2017

@GiorgioG Supporting .NET Core and MSBuild 15-based projects is the top item for @KevinRansom. I wouldn't interpret numbers in the list as an overall priority.

@smoothdeveloper

This comment has been minimized.

Show comment
Hide comment
@smoothdeveloper

smoothdeveloper Feb 9, 2017

Contributor

@GiorgioG I'm not sure if the order in Immediate Roadmap for 2017 is indication (localization and build optimization are high but they don't seem to be the most blocking) but I see it is first item @KevinRansom has on the detailed list.

Contributor

smoothdeveloper commented Feb 9, 2017

@GiorgioG I'm not sure if the order in Immediate Roadmap for 2017 is indication (localization and build optimization are high but they don't seem to be the most blocking) but I see it is first item @KevinRansom has on the detailed list.

@charlesroddie

This comment has been minimized.

Show comment
Hide comment
@charlesroddie

charlesroddie Feb 9, 2017

Why isn't Windows Store support (related to .NET Native support) on this list?

charlesroddie commented Feb 9, 2017

Why isn't Windows Store support (related to .NET Native support) on this list?

@KevinRansom

This comment has been minimized.

Show comment
Hide comment
@KevinRansom

KevinRansom Feb 9, 2017

Contributor

@charlesroddie Because that depends on the Core CLR team improving support for a couple of big items. dotnet native is and AOT compilation are absolutely a goal for us ... they just are longer term than this roadmap anticipates.

I hope this helps

Kevin

Contributor

KevinRansom commented Feb 9, 2017

@charlesroddie Because that depends on the Core CLR team improving support for a couple of big items. dotnet native is and AOT compilation are absolutely a goal for us ... they just are longer term than this roadmap anticipates.

I hope this helps

Kevin

@KevinRansom

This comment has been minimized.

Show comment
Hide comment
@KevinRansom

KevinRansom Feb 9, 2017

Contributor

@georigiog @smoothdeveloper I am looking at it right now ... I am in fact torn about how to proceed.

I would like to go CPS since that is the long term right plan ... however ... CPS fundamentally orders files alphabetically ... this has been a long known bug in CPS and is still not fixed. It has not been fixed because .. .csproj and .vbproj don't need it, and .fsproj doesn't load into CPS. It's been kind of a chicken and egg problem. Also CPS isn't OSS so fixing it's behavior requires somewhat more ceremony than we are used to.
Also would require that we continue to ship the old project system for legacy projects.

An alternative approach and in the short term less risky approach is to fix the F# project system to load them. However ... there are a bunch of nice but large work items that we would then not have.

  1. Built in support for Roslyn multi-targeting, especially intellisense
    (API narrowing --- select two target platforms and get the sommon subset of APIs).
  2. Support for package references

However ... file ordering will work ....

Anyway I am torn ....

Probably an overshare .... please forgive me if it was too much info ...

Kevin

Contributor

KevinRansom commented Feb 9, 2017

@georigiog @smoothdeveloper I am looking at it right now ... I am in fact torn about how to proceed.

I would like to go CPS since that is the long term right plan ... however ... CPS fundamentally orders files alphabetically ... this has been a long known bug in CPS and is still not fixed. It has not been fixed because .. .csproj and .vbproj don't need it, and .fsproj doesn't load into CPS. It's been kind of a chicken and egg problem. Also CPS isn't OSS so fixing it's behavior requires somewhat more ceremony than we are used to.
Also would require that we continue to ship the old project system for legacy projects.

An alternative approach and in the short term less risky approach is to fix the F# project system to load them. However ... there are a bunch of nice but large work items that we would then not have.

  1. Built in support for Roslyn multi-targeting, especially intellisense
    (API narrowing --- select two target platforms and get the sommon subset of APIs).
  2. Support for package references

However ... file ordering will work ....

Anyway I am torn ....

Probably an overshare .... please forgive me if it was too much info ...

Kevin

@smoothdeveloper

This comment has been minimized.

Show comment
Hide comment
@smoothdeveloper

smoothdeveloper Feb 9, 2017

Contributor

@KevinRansom thanks, it is good to know what are the ongoing struggles.

It seems most people are looking for a quick fix to get .net core fsproj to load in VS, we all understand going toward CPS is a lot more work and will bring a lot to the table.

Getting out of box VS support for F# .net core projects is going to help with adoption of both .net core and F# for xplat (for windows/VS users), this is a quick win if we roughly what needs to be dealt with in current project system.

Edit: should the discussion regarding that focused item go to #2394 ?

Contributor

smoothdeveloper commented Feb 9, 2017

@KevinRansom thanks, it is good to know what are the ongoing struggles.

It seems most people are looking for a quick fix to get .net core fsproj to load in VS, we all understand going toward CPS is a lot more work and will bring a lot to the table.

Getting out of box VS support for F# .net core projects is going to help with adoption of both .net core and F# for xplat (for windows/VS users), this is a quick win if we roughly what needs to be dealt with in current project system.

Edit: should the discussion regarding that focused item go to #2394 ?

@GiorgioG

This comment has been minimized.

Show comment
Hide comment
@GiorgioG

GiorgioG Feb 9, 2017

@KevinRansom Thanks for the details Kevin - it's helpful to understand that there are complex issues / tradeoffs / decisions to be considered.

GiorgioG commented Feb 9, 2017

@KevinRansom Thanks for the details Kevin - it's helpful to understand that there are complex issues / tradeoffs / decisions to be considered.

@enricosada

This comment has been minimized.

Show comment
Hide comment
@enricosada

enricosada Feb 9, 2017

Contributor

Migrate the OSS Build to the latest .NET CLI and MSBuild and
The .NET CLI does not use project.json anymore, but our OSS Build still relies on that
The .NET CLI uses MSBuild 15 and PackageReferences, which we need to support

I'd like to do that.
Speaking with @cartermp , we can discuss (in another issue) how to that with @brettfo and community.
I already have a PR about that. Need to just complete it building also fsharp.core/fsharp.compiler, and replacing build coreclr for now, as @dsyme suggested
Signing/localization too, can be done like dotnet/cli team (ref .xlf localization files really nice ihmo so we can contribute to localization too!, like other ms projects)

Contributor

enricosada commented Feb 9, 2017

Migrate the OSS Build to the latest .NET CLI and MSBuild and
The .NET CLI does not use project.json anymore, but our OSS Build still relies on that
The .NET CLI uses MSBuild 15 and PackageReferences, which we need to support

I'd like to do that.
Speaking with @cartermp , we can discuss (in another issue) how to that with @brettfo and community.
I already have a PR about that. Need to just complete it building also fsharp.core/fsharp.compiler, and replacing build coreclr for now, as @dsyme suggested
Signing/localization too, can be done like dotnet/cli team (ref .xlf localization files really nice ihmo so we can contribute to localization too!, like other ms projects)

@KevinRansom

This comment has been minimized.

Show comment
Hide comment
@KevinRansom

KevinRansom Feb 9, 2017

Contributor

@enricosada ... reorganizing the build is about lot more than just changing the way we build the coreclr. The current build is absolutely horrific, and we should take a stab at fixing it all up.

Contributor

KevinRansom commented Feb 9, 2017

@enricosada ... reorganizing the build is about lot more than just changing the way we build the coreclr. The current build is absolutely horrific, and we should take a stab at fixing it all up.

@enricosada

This comment has been minimized.

Show comment
Hide comment
@enricosada

enricosada Feb 9, 2017

Contributor

@KevinRansom i want to do that too (xplat, no hacks, from clone -> signed packages + vsix, like dotnet/cli does for example). But incrementally, first coreclr so we can clean and use sdk and unblock netstandard2,0 if needed, After that, the rest. with sdk i can remove pretty really a lot, see my PR #2250 (comment) about cleanup and future work.

I have some ideas, we can discuss goals and how to proceed in another issue maybe? i dont want to monopolize this issue 😄 i am always a lot verbose

Contributor

enricosada commented Feb 9, 2017

@KevinRansom i want to do that too (xplat, no hacks, from clone -> signed packages + vsix, like dotnet/cli does for example). But incrementally, first coreclr so we can clean and use sdk and unblock netstandard2,0 if needed, After that, the rest. with sdk i can remove pretty really a lot, see my PR #2250 (comment) about cleanup and future work.

I have some ideas, we can discuss goals and how to proceed in another issue maybe? i dont want to monopolize this issue 😄 i am always a lot verbose

@KevinRansom

This comment has been minimized.

Show comment
Hide comment
@KevinRansom

KevinRansom Feb 9, 2017

Contributor

@enricosada I will take another look and suggest an approach.

Contributor

KevinRansom commented Feb 9, 2017

@enricosada I will take another look and suggest an approach.

@Huqin-China

This comment has been minimized.

Show comment
Hide comment
@Huqin-China

Huqin-China Feb 10, 2017

Thanks for your work and achievements!
F# is a nice language,it will become perfect one after VS's full support.
VS is called "the most powerful IDE in Universe" in China.
Nice language+Great IDE,The Gospel of dummy Programmers

Huqin-China commented Feb 10, 2017

Thanks for your work and achievements!
F# is a nice language,it will become perfect one after VS's full support.
VS is called "the most powerful IDE in Universe" in China.
Nice language+Great IDE,The Gospel of dummy Programmers

@dbettin

This comment has been minimized.

Show comment
Hide comment
@dbettin

dbettin Feb 10, 2017

This also takes a dependency on RefEmit. We’ll need to investigate this further, since it’s currently not on the .NET Core 2.0 roadmap

How high priority is this issue? .Net core engenders growth in F#, but we can't do it without type providers.

dbettin commented Feb 10, 2017

This also takes a dependency on RefEmit. We’ll need to investigate this further, since it’s currently not on the .NET Core 2.0 roadmap

How high priority is this issue? .Net core engenders growth in F#, but we can't do it without type providers.

@cartermp

This comment has been minimized.

Show comment
Hide comment
@cartermp

cartermp Feb 10, 2017

Contributor

@dbettin The breakdown is actually as follows:

Erasing Type Providers (which are more common) should not require System.Reflection.Emit, but Generative Type Providers will. We'll first need to ensure that with the .NET Standard 2.0 APIs coming along, that we can at least support Erasing Type Providers. If that's the case, then many of the type providers in the wild could conceivably be used, assuming there are no other issues we run into.

For Quotations, it's a somewhat similar story. They don't require System.Reflection.Emit, but they are needed for fully-fledged quotation evaluators/compilers, and are needed if they are used as input to a Generative Type Provider.

What I think may be likely is that we'll have support for the "95% case" in these areas, but we could still be blocking key libraries and library authors if they are building full-on quotation compilers and Generative Type Providers.

All of the above is assuming that we don't do any work in those areas ourselves. @KevinRansom can speak more towards the feasibility of that, but given the amount of work we're doing right now, I don't find it likely that rewrites of those areas of TPs and Quotations will come from someone in Redmond between now and .NET Standard/.NET Core 2.0.

Contributor

cartermp commented Feb 10, 2017

@dbettin The breakdown is actually as follows:

Erasing Type Providers (which are more common) should not require System.Reflection.Emit, but Generative Type Providers will. We'll first need to ensure that with the .NET Standard 2.0 APIs coming along, that we can at least support Erasing Type Providers. If that's the case, then many of the type providers in the wild could conceivably be used, assuming there are no other issues we run into.

For Quotations, it's a somewhat similar story. They don't require System.Reflection.Emit, but they are needed for fully-fledged quotation evaluators/compilers, and are needed if they are used as input to a Generative Type Provider.

What I think may be likely is that we'll have support for the "95% case" in these areas, but we could still be blocking key libraries and library authors if they are building full-on quotation compilers and Generative Type Providers.

All of the above is assuming that we don't do any work in those areas ourselves. @KevinRansom can speak more towards the feasibility of that, but given the amount of work we're doing right now, I don't find it likely that rewrites of those areas of TPs and Quotations will come from someone in Redmond between now and .NET Standard/.NET Core 2.0.

@dbettin

This comment has been minimized.

Show comment
Hide comment
@dbettin

dbettin Feb 10, 2017

Thanks @cartermp. It might be helpful to break these out into separate issues. And maybe assign an up for grabs label to issues that are not assigned to Redmond devs?

dbettin commented Feb 10, 2017

Thanks @cartermp. It might be helpful to break these out into separate issues. And maybe assign an up for grabs label to issues that are not assigned to Redmond devs?

@dsyme

This comment has been minimized.

Show comment
Hide comment
@dsyme

dsyme Feb 10, 2017

Contributor

@Huqin-China Thanks for the perspectives from China!

Contributor

dsyme commented Feb 10, 2017

@Huqin-China Thanks for the perspectives from China!

@KevinRansom

This comment has been minimized.

Show comment
Hide comment
@KevinRansom

KevinRansom Feb 10, 2017

Contributor

@dbettin @cartermp

The problem with generative TypeProviders is that ref emit on coreclr doesn't implement Save(). Ref emit is not actually a part of .Net Standard 2.0 the System.Reflection.Emit package will work with fine with .Net Standard 2.0, it's just those Apis are not part of the .Net Standard set of Apis and so ... there is no urgency to improve it's desktop compatibility. The problem for F# is that generative type providers need to produce a P.E file and since the the Save() API doesn't exist, we need a clever solution to that problem. There are in fact plenty of approaches we could take ... we just haven't settled on one that is the obvious winner.

I cornered Jan Kotas in the corridor the other day and tried to push him to commit to getting us Save, he urged us to seek other solutions ...

So ... we need an alternate solution, regardless until .Net Standard 2.0 we can't do much with type providers given that Type has a private constructor on the coreclr, at least in the reference assemblies it is, the implementation still has a protected constructor. So I suppose we could do type reference magic to get something working.

As for up for grabs ... just express an interest in an area you want to work on and start a discussion. Helping out is really very easy. Most people just pick something they want to do and start work on it.

Kevin

Contributor

KevinRansom commented Feb 10, 2017

@dbettin @cartermp

The problem with generative TypeProviders is that ref emit on coreclr doesn't implement Save(). Ref emit is not actually a part of .Net Standard 2.0 the System.Reflection.Emit package will work with fine with .Net Standard 2.0, it's just those Apis are not part of the .Net Standard set of Apis and so ... there is no urgency to improve it's desktop compatibility. The problem for F# is that generative type providers need to produce a P.E file and since the the Save() API doesn't exist, we need a clever solution to that problem. There are in fact plenty of approaches we could take ... we just haven't settled on one that is the obvious winner.

I cornered Jan Kotas in the corridor the other day and tried to push him to commit to getting us Save, he urged us to seek other solutions ...

So ... we need an alternate solution, regardless until .Net Standard 2.0 we can't do much with type providers given that Type has a private constructor on the coreclr, at least in the reference assemblies it is, the implementation still has a protected constructor. So I suppose we could do type reference magic to get something working.

As for up for grabs ... just express an interest in an area you want to work on and start a discussion. Helping out is really very easy. Most people just pick something they want to do and start work on it.

Kevin

@dbettin

This comment has been minimized.

Show comment
Hide comment
@dbettin

dbettin Feb 10, 2017

@KevinRansom Thanks. My point around the up for grabs is it would beneficial to break these up so we can start tracking these issues independently.

dbettin commented Feb 10, 2017

@KevinRansom Thanks. My point around the up for grabs is it would beneficial to break these up so we can start tracking these issues independently.

@smoothdeveloper

This comment has been minimized.

Show comment
Hide comment
@smoothdeveloper

smoothdeveloper Feb 10, 2017

Contributor

@dbettin do you mind creating the few issues you have in mind? I think with github option, the maintainers can expand the description with additional technical and contextual information.

Contributor

smoothdeveloper commented Feb 10, 2017

@dbettin do you mind creating the few issues you have in mind? I think with github option, the maintainers can expand the description with additional technical and contextual information.

@panesofglass

This comment has been minimized.

Show comment
Hide comment
@panesofglass

panesofglass Feb 11, 2017

This roadmap makes it appear that, for my purposes, VS 2017 RTM is really more of an alpha release for F# support, at least wrt .NET Core. Will .NET 4.6 projects continue to work, or should we stick to VS 2015 and/or VS Code?

panesofglass commented Feb 11, 2017

This roadmap makes it appear that, for my purposes, VS 2017 RTM is really more of an alpha release for F# support, at least wrt .NET Core. Will .NET 4.6 projects continue to work, or should we stick to VS 2015 and/or VS Code?

@cartermp

This comment has been minimized.

Show comment
Hide comment
@cartermp

cartermp Feb 11, 2017

Contributor

.NET Framework 4.6 projects should continue to work, yes. Addressing any regressions there is a top priority for us. RC4 is a good target to validate this on. The bits in there are the bits which are shipping in VS 2017 RTM, barring some unexpected, massive error on our part.

Contributor

cartermp commented Feb 11, 2017

.NET Framework 4.6 projects should continue to work, yes. Addressing any regressions there is a top priority for us. RC4 is a good target to validate this on. The bits in there are the bits which are shipping in VS 2017 RTM, barring some unexpected, massive error on our part.

@OnurGumus

This comment has been minimized.

Show comment
Hide comment
@OnurGumus

OnurGumus Feb 12, 2017

Contributor

Not a single word about .NET Native or UWP support. Nice!

Contributor

OnurGumus commented Feb 12, 2017

Not a single word about .NET Native or UWP support. Nice!

@vasily-kirichenko

This comment has been minimized.

Show comment
Hide comment
Contributor

vasily-kirichenko commented Feb 12, 2017

@OnurGumus

This comment has been minimized.

Show comment
Hide comment
@OnurGumus

OnurGumus Feb 12, 2017

Contributor

@vasily-kirichenko ah ok thanks. Didn't read all the comments.

Contributor

OnurGumus commented Feb 12, 2017

@vasily-kirichenko ah ok thanks. Didn't read all the comments.

@xperiandri

This comment has been minimized.

Show comment
Hide comment
@xperiandri

xperiandri Mar 7, 2017

What about project template for F# Roslyn analyzer?

xperiandri commented Mar 7, 2017

What about project template for F# Roslyn analyzer?

@cartermp

This comment has been minimized.

Show comment
Hide comment
@cartermp

cartermp Mar 7, 2017

Contributor

@xperiandri Currently that's not possible, since F# does not use the same semantic model that Roslyn uses.. What I believe you're referring to is the F# lightbulbs. These are controlled by adding a new type in the F# editor project which exports itself as a codefix provider, e.g. this. It registers an error code to trigger on, and when that code is registered by the F# diagnostics service, the code fix will trigger the lightbulb. I'm not sure that there's a good way to get a template for that going.

Contributor

cartermp commented Mar 7, 2017

@xperiandri Currently that's not possible, since F# does not use the same semantic model that Roslyn uses.. What I believe you're referring to is the F# lightbulbs. These are controlled by adding a new type in the F# editor project which exports itself as a codefix provider, e.g. this. It registers an error code to trigger on, and when that code is registered by the F# diagnostics service, the code fix will trigger the lightbulb. I'm not sure that there's a good way to get a template for that going.

@xperiandri

This comment has been minimized.

Show comment
Hide comment
@xperiandri

xperiandri Mar 7, 2017

Why not? At least it can bootstrap fixes creation.
What about light bulb UI? Is it already reusable or still locked to C#/VB analyzers?

xperiandri commented Mar 7, 2017

Why not? At least it can bootstrap fixes creation.
What about light bulb UI? Is it already reusable or still locked to C#/VB analyzers?

@cartermp

This comment has been minimized.

Show comment
Hide comment
@cartermp

cartermp Mar 7, 2017

Contributor

@xperiandri There's really two problems here, but first I'll clear this up

Lightbulbs aren't tied to C#/VB. We use them today, with Roslyn Workspaces as our vehicle. F# tools now sit on the Roslyn Workspace layer, which is why we're able to use the same UI.

Triggering Lightbulbs is only possible within the F# Tools repo itself right now. There is no extensibility model. That kind of model would have to use the Roslyn Analysis Platform, which we cannot interact with because we have our own semantic model. We don't share the same semantic model as C# and VB.

Thus, any template could only be useful when developed within the F# Tools themselves. After that, any template would also not trigger a lightbulb by default - they're triggered by a sepcific F# error code, which you would have to supply yourself. So at best, a template would:

  1. Only work with the Visual F# Tools themselves
  2. Not trigger until you add the error code you want the lightbulb to trigger with

Given that, and that it's pretty easy to just copy/paste some code from one code fix provider and change some names around, we don't have a template. We could consider such a template for people looking to improve these specific tools as part of a Visual F# Tools Developer Guide, perhaps.

Contributor

cartermp commented Mar 7, 2017

@xperiandri There's really two problems here, but first I'll clear this up

Lightbulbs aren't tied to C#/VB. We use them today, with Roslyn Workspaces as our vehicle. F# tools now sit on the Roslyn Workspace layer, which is why we're able to use the same UI.

Triggering Lightbulbs is only possible within the F# Tools repo itself right now. There is no extensibility model. That kind of model would have to use the Roslyn Analysis Platform, which we cannot interact with because we have our own semantic model. We don't share the same semantic model as C# and VB.

Thus, any template could only be useful when developed within the F# Tools themselves. After that, any template would also not trigger a lightbulb by default - they're triggered by a sepcific F# error code, which you would have to supply yourself. So at best, a template would:

  1. Only work with the Visual F# Tools themselves
  2. Not trigger until you add the error code you want the lightbulb to trigger with

Given that, and that it's pretty easy to just copy/paste some code from one code fix provider and change some names around, we don't have a template. We could consider such a template for people looking to improve these specific tools as part of a Visual F# Tools Developer Guide, perhaps.

@idg10

This comment has been minimized.

Show comment
Hide comment
@idg10

idg10 Mar 8, 2017

In his comment on 9th Feb, @KevinRansom talks about the tradeoff between CPS vs fixing the existing F# project system to load msbuild 15 files. One particular benefit of CPS was "Support for package references."

Does this mean that if you don't go down the CPS route, package references will be unavailable?

That's distressing but also confusing. I was under the impression that if you build from the command line, it's possible to use a PackageReference in an MSBuild-15-based fsproj now. (At least, I remember seeing an example showing this.) So if you don't do CPS, what will the situation with PackageReferences be? Will they not work? Will they work but need manual authoring of the fsproj to add them?

The thing I most urgently want is the ability to use package references in an fsproj, and to have them work transitively across external projects (including C# ones). E.g., if my F# project has a reference to a csproj in the same solution, and that csproj has a PackageReference to some NuGet package, my F# project will also implicitly have access to that same package without needing to add it explicitly to my csproj.

(I don't care about .NET Core by the way. I'm targetting .NET FX 4.6.1. I just want to escape from the insanity of packages.config.)

idg10 commented Mar 8, 2017

In his comment on 9th Feb, @KevinRansom talks about the tradeoff between CPS vs fixing the existing F# project system to load msbuild 15 files. One particular benefit of CPS was "Support for package references."

Does this mean that if you don't go down the CPS route, package references will be unavailable?

That's distressing but also confusing. I was under the impression that if you build from the command line, it's possible to use a PackageReference in an MSBuild-15-based fsproj now. (At least, I remember seeing an example showing this.) So if you don't do CPS, what will the situation with PackageReferences be? Will they not work? Will they work but need manual authoring of the fsproj to add them?

The thing I most urgently want is the ability to use package references in an fsproj, and to have them work transitively across external projects (including C# ones). E.g., if my F# project has a reference to a csproj in the same solution, and that csproj has a PackageReference to some NuGet package, my F# project will also implicitly have access to that same package without needing to add it explicitly to my csproj.

(I don't care about .NET Core by the way. I'm targetting .NET FX 4.6.1. I just want to escape from the insanity of packages.config.)

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Mar 8, 2017

Contributor
Contributor

forki commented Mar 8, 2017

@idg10

This comment has been minimized.

Show comment
Hide comment
@idg10

idg10 Mar 8, 2017

Thank you @forki for confirming that you can indeed use PackageReference from the command line. (As I said, I thought this was so but wasn't certain.)

Rereading my comment I realised I didn't make it sufficiently clear that it's Visual Studio I'm interested in. I know it doesn't work today, but there are plans afoot to change this, and there's a tradeoff between two different ways this might be handled.

And that's what I was trying to understand: I gather there's a choice between moving to CPS and fixing up the existing project system to cope with the new fsproj capabilities.

Kevin's comment seemed to imply that if they go down the latter path - just fixing up the existing system - this would have an impact on package reference support in VS. I'd like to understand what that impact would be.

idg10 commented Mar 8, 2017

Thank you @forki for confirming that you can indeed use PackageReference from the command line. (As I said, I thought this was so but wasn't certain.)

Rereading my comment I realised I didn't make it sufficiently clear that it's Visual Studio I'm interested in. I know it doesn't work today, but there are plans afoot to change this, and there's a tradeoff between two different ways this might be handled.

And that's what I was trying to understand: I gather there's a choice between moving to CPS and fixing up the existing project system to cope with the new fsproj capabilities.

Kevin's comment seemed to imply that if they go down the latter path - just fixing up the existing system - this would have an impact on package reference support in VS. I'd like to understand what that impact would be.

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Mar 8, 2017

Contributor
Contributor

forki commented Mar 8, 2017

@idg10

This comment has been minimized.

Show comment
Hide comment
@idg10

idg10 Mar 8, 2017

OK, so if I understand, this means that it's definitely going to be the CPS route, and F# will at some point get full support for package references on an equal footing with C#? Fantastic.

Are the roslyn updates you refer to dotnet/project-system#1670 ?

Is there any place I can keep track of F#'s progress towards being able to use new fsproj files from Visual Studio? I posted to this thread because when I looked in the Issues I didn't manage to find anything that was obviously tracking progress on this - Kevin's comment on this thread was the only thing I'd found.

After some more digging I've found a check list of things to be done here but that doesn't look like a definitive work item for tracking this stuff - more a proposal of what one might look like.

I'd like to be able to keep an eye on this partly so I can have some idea of when it'll arrive, but also so I can, if possible, try out work in progress to see if it works for me, and provide feedback if appropriate. But I've not been able to work out where I should be looking for this.

idg10 commented Mar 8, 2017

OK, so if I understand, this means that it's definitely going to be the CPS route, and F# will at some point get full support for package references on an equal footing with C#? Fantastic.

Are the roslyn updates you refer to dotnet/project-system#1670 ?

Is there any place I can keep track of F#'s progress towards being able to use new fsproj files from Visual Studio? I posted to this thread because when I looked in the Issues I didn't manage to find anything that was obviously tracking progress on this - Kevin's comment on this thread was the only thing I'd found.

After some more digging I've found a check list of things to be done here but that doesn't look like a definitive work item for tracking this stuff - more a proposal of what one might look like.

I'd like to be able to keep an eye on this partly so I can have some idea of when it'll arrive, but also so I can, if possible, try out work in progress to see if it works for me, and provide feedback if appropriate. But I've not been able to work out where I should be looking for this.

@cartermp

This comment has been minimized.

Show comment
Hide comment
@cartermp

cartermp Mar 8, 2017

Contributor

Yup, just to confirm that @forki is right. F# will be using CPS in Visual Studio and adopt the new MSBuild PackageReference and other goodies. I highly recommend using the CLI and VSCode to experiment with it today. Any feedback you can provide about it would be helpful.

We'll also have a more definitive tracking issue once we have @brettfo working on it. We're still finalizing some things w.r.t our internal builds and release management.

Contributor

cartermp commented Mar 8, 2017

Yup, just to confirm that @forki is right. F# will be using CPS in Visual Studio and adopt the new MSBuild PackageReference and other goodies. I highly recommend using the CLI and VSCode to experiment with it today. Any feedback you can provide about it would be helpful.

We'll also have a more definitive tracking issue once we have @brettfo working on it. We're still finalizing some things w.r.t our internal builds and release management.

@xperiandri

This comment has been minimized.

Show comment
Hide comment
@xperiandri

xperiandri Mar 8, 2017

@cartermp, what about snippets?
#1498

I can't see neither folder for snippets in Visual Studio user folder nor a command in context menu in Visual Studio.

xperiandri commented Mar 8, 2017

@cartermp, what about snippets?
#1498

I can't see neither folder for snippets in Visual Studio user folder nor a command in context menu in Visual Studio.

@cartermp

This comment has been minimized.

Show comment
Hide comment
@cartermp

cartermp Mar 9, 2017

Contributor

@xperiandri Not on the immediate roadmap, but I know that @brettfo was looking at this a while back. He might pick that back up in a while. For sure, snippets are something we're lacking in right now.

Contributor

cartermp commented Mar 9, 2017

@xperiandri Not on the immediate roadmap, but I know that @brettfo was looking at this a while back. He might pick that back up in a while. For sure, snippets are something we're lacking in right now.

@KevinRansom

This comment has been minimized.

Show comment
Hide comment
@KevinRansom

KevinRansom Mar 9, 2017

Contributor

@xperiandri the roadmap sets the general direction, and identifies the large feature areas targeted. We welcome community contributions of features that conform to the general direction we are headed whether they are called out in the roadmap or not. Similarly smaller unmentioned features may well be handled by us, en-route as it were.

So that snippets, folders and context menu changes are not in the roadmap, it's because they are below the level of detail intended for it.

Does that help?

Kevin

Contributor

KevinRansom commented Mar 9, 2017

@xperiandri the roadmap sets the general direction, and identifies the large feature areas targeted. We welcome community contributions of features that conform to the general direction we are headed whether they are called out in the roadmap or not. Similarly smaller unmentioned features may well be handled by us, en-route as it were.

So that snippets, folders and context menu changes are not in the roadmap, it's because they are below the level of detail intended for it.

Does that help?

Kevin

@7sharp9

This comment has been minimized.

Show comment
Hide comment
@7sharp9

7sharp9 Mar 21, 2017

One of the big things is that generative type providers service the wider ecosystem not just F#, they are the most important aspect in that respect.

Unchecked quotations for generative providers is also something that sorely needed to avoid having to reflectively call quotation builders to build the type provider.

7sharp9 commented Mar 21, 2017

One of the big things is that generative type providers service the wider ecosystem not just F#, they are the most important aspect in that respect.

Unchecked quotations for generative providers is also something that sorely needed to avoid having to reflectively call quotation builders to build the type provider.

@21c-HK

This comment has been minimized.

Show comment
Hide comment
@21c-HK

21c-HK Apr 11, 2017

@cartermp Could you please change the number/bullet points to check boxes in the original post so that it's possible to track the current status of the individual work items?

21c-HK commented Apr 11, 2017

@cartermp Could you please change the number/bullet points to check boxes in the original post so that it's possible to track the current status of the individual work items?

@enricosada enricosada referenced this issue Apr 11, 2017

Closed

run ionide with .NET Core #78

2 of 7 tasks complete
@Artur2

This comment has been minimized.

Show comment
Hide comment
@Artur2

Artur2 Apr 20, 2017

Hi guys! What about automatically list members like in C# ?

Artur2 commented Apr 20, 2017

Hi guys! What about automatically list members like in C# ?

@dsyme

This comment has been minimized.

Show comment
Hide comment
@dsyme

dsyme May 18, 2017

Contributor

Closing in preference to most recent announcements here #3069

Contributor

dsyme commented May 18, 2017

Closing in preference to most recent announcements here #3069

@cartermp

This comment has been minimized.

Show comment
Hide comment
@cartermp

cartermp Aug 26, 2017

Contributor

Closing old discussion

Contributor

cartermp commented Aug 26, 2017

Closing old discussion

@cartermp cartermp closed this Aug 26, 2017

@masaeedu

This comment has been minimized.

Show comment
Hide comment
@masaeedu

masaeedu Oct 19, 2017

@cartermp Is there a single issue we can follow to keep an eye on the status of F# support for VS 2017? The table here still indicates VS 2017 doesn't support dotnet -lang f# projects, and I can see that it is not possible to use Intellisense or type hints.

masaeedu commented Oct 19, 2017

@cartermp Is there a single issue we can follow to keep an eye on the status of F# support for VS 2017? The table here still indicates VS 2017 doesn't support dotnet -lang f# projects, and I can see that it is not possible to use Intellisense or type hints.

@cartermp

This comment has been minimized.

Show comment
Hide comment
@cartermp

cartermp Oct 19, 2017

Contributor

@masaeedu The VS 2017 release notes track what's available for the current non-preview release, and there are links to past release notes which contain lists of features.

There is single issue to track the status of F# support for VS 2017, nor will there be. There are simply too many things to track, some of which have been in the product since its inception.

Contributor

cartermp commented Oct 19, 2017

@masaeedu The VS 2017 release notes track what's available for the current non-preview release, and there are links to past release notes which contain lists of features.

There is single issue to track the status of F# support for VS 2017, nor will there be. There are simply too many things to track, some of which have been in the product since its inception.

@GiorgioG

This comment has been minimized.

Show comment
Hide comment
@GiorgioG

GiorgioG Oct 19, 2017

@masaeedu - Not to beat a dead horse, but we've been waiting for an RTM release of this since May when VS2017 first RTM'd. We were then told it would likely come in the July release of VS, we're now nearing the tail end of October with no clear idea when we'll get it. It's not @cartermp 's fault, just the reality that MS has not made it a high priority (judging by their actions, not their words.) In summary, if you want to use F#, use VSCode, it has excellent support for F#, as long as you realize it's not Visual Studio, it's a souped up text editor.

GiorgioG commented Oct 19, 2017

@masaeedu - Not to beat a dead horse, but we've been waiting for an RTM release of this since May when VS2017 first RTM'd. We were then told it would likely come in the July release of VS, we're now nearing the tail end of October with no clear idea when we'll get it. It's not @cartermp 's fault, just the reality that MS has not made it a high priority (judging by their actions, not their words.) In summary, if you want to use F#, use VSCode, it has excellent support for F#, as long as you realize it's not Visual Studio, it's a souped up text editor.

@cartermp

This comment has been minimized.

Show comment
Hide comment
@cartermp

cartermp Oct 19, 2017

Contributor

@GiorgioG Two things:

a. Things change, such as releases, especially when things are difficult.
b. .NET Core has been the single highest priority for F#, and since we delivered stable support for .NET Core 2.0 and .NET Standard 2.0, we're focusing solely on the tooling inside of VS 2017.

Contributor

cartermp commented Oct 19, 2017

@GiorgioG Two things:

a. Things change, such as releases, especially when things are difficult.
b. .NET Core has been the single highest priority for F#, and since we delivered stable support for .NET Core 2.0 and .NET Standard 2.0, we're focusing solely on the tooling inside of VS 2017.

@GiorgioG

This comment has been minimized.

Show comment
Hide comment
@GiorgioG

GiorgioG Oct 19, 2017

@cartermp

a. I understand I'm a software dev too ;)
b. Totally understand, but correct me if I'm wrong, there's VS infrastructure outside of the F# team's control that needs to be changed to support some of the F# specifics around compilation order that isn't/wasn't there? That's what I meant by MS not prioritizing it, not saying the F# team isn't focused on it.

GiorgioG commented Oct 19, 2017

@cartermp

a. I understand I'm a software dev too ;)
b. Totally understand, but correct me if I'm wrong, there's VS infrastructure outside of the F# team's control that needs to be changed to support some of the F# specifics around compilation order that isn't/wasn't there? That's what I meant by MS not prioritizing it, not saying the F# team isn't focused on it.

@masaeedu

This comment has been minimized.

Show comment
Hide comment
@masaeedu

masaeedu Oct 19, 2017

@cartermp I'm looking for some kind of checklist or issue label for the VS 2017 extension that will let me distinguish "oh this just isn't implemented yet" from "oh, I'm an idiot I just have it set up wrong".

If there isn't such a thing, is there an issue tracking implementation of Intellisense for dotnet CLI generated F# projects in VS 2017? I'm searching for "Intellisense" in the github issues, which brings up lots of different bugs/feature requests for Intellisense; which is incongruent with my experience of Intellisense simply not working all.

I appreciate the link to the release notes, but they aren't very easy to search for what I need.

masaeedu commented Oct 19, 2017

@cartermp I'm looking for some kind of checklist or issue label for the VS 2017 extension that will let me distinguish "oh this just isn't implemented yet" from "oh, I'm an idiot I just have it set up wrong".

If there isn't such a thing, is there an issue tracking implementation of Intellisense for dotnet CLI generated F# projects in VS 2017? I'm searching for "Intellisense" in the github issues, which brings up lots of different bugs/feature requests for Intellisense; which is incongruent with my experience of Intellisense simply not working all.

I appreciate the link to the release notes, but they aren't very easy to search for what I need.

@cartermp

This comment has been minimized.

Show comment
Hide comment
@cartermp

cartermp Oct 19, 2017

Contributor

@GiorgioG

Totally understand, but correct me if I'm wrong, there's VS infrastructure outside of the F# team's control that needs to be changed to support some of the F# specifics around compilation order that isn't/wasn't there? That's what I meant by MS not prioritizing it, not saying the F# team isn't focused on it.

In this case, there are three layers:

F#

.NET project system, which is a plugin to the bottom later

CPS (Common project system), which is inside of VS

CPS has implemented a component which respects F# file ordering, but this is known as a "Data flow". It used to not respect ordering, so IntelliSense would be hosed no matter what you did. This component doesn't control the UI, it just makes sure that when we pass the file ordering down into the underlying project system, that this file ordering is preserved. CPS is closed-source and internal to VS, and with no public bug tracker.

The .NET project system plugin to CPS needs to effectively wire up the UI to use that data flow when presenting F# files in compilation order. However, given that:

(a) The project system now preserves the ordering of files, thus allowing IntelliSense to work (modulo our last bit of work here, which enables project-to-project references and seeing symbols from newly-added files in IntelliSense)
(b) Project files are palatable and can be opened without unloading a project

We're not blocking on the 15.5 release to get the visual ordering in the file tree. The issue is being tracked here, and although it's still an annoyance, it's not the end of the world. We still need to get gestures added, and CPS is also looking into click-and-drag in the tree, which would allow you to order using the mouse like VS for Mac. The project system has had to deliver an immense amount of scope in a short amount of time, so issues like this which don't prevent someone from using the product aren't given top priority. But it's coming.

@masaeedu My advice would be to try out VS 2017 15.5 Preview 1, which works aside from the following:

  • If you add a new file, the constructs in that file may not be visible to files which use it
  • If you add a new project and add a reference to it from an F#/.NET Core project, you won't get IntelliSense for things you use

These two issues are addressed in #3777 and targeted at the 15.5 release. That said, IntelliSense works fully for .NET Core SDK-based projects in the preview, modulo those two issues.

Contributor

cartermp commented Oct 19, 2017

@GiorgioG

Totally understand, but correct me if I'm wrong, there's VS infrastructure outside of the F# team's control that needs to be changed to support some of the F# specifics around compilation order that isn't/wasn't there? That's what I meant by MS not prioritizing it, not saying the F# team isn't focused on it.

In this case, there are three layers:

F#

.NET project system, which is a plugin to the bottom later

CPS (Common project system), which is inside of VS

CPS has implemented a component which respects F# file ordering, but this is known as a "Data flow". It used to not respect ordering, so IntelliSense would be hosed no matter what you did. This component doesn't control the UI, it just makes sure that when we pass the file ordering down into the underlying project system, that this file ordering is preserved. CPS is closed-source and internal to VS, and with no public bug tracker.

The .NET project system plugin to CPS needs to effectively wire up the UI to use that data flow when presenting F# files in compilation order. However, given that:

(a) The project system now preserves the ordering of files, thus allowing IntelliSense to work (modulo our last bit of work here, which enables project-to-project references and seeing symbols from newly-added files in IntelliSense)
(b) Project files are palatable and can be opened without unloading a project

We're not blocking on the 15.5 release to get the visual ordering in the file tree. The issue is being tracked here, and although it's still an annoyance, it's not the end of the world. We still need to get gestures added, and CPS is also looking into click-and-drag in the tree, which would allow you to order using the mouse like VS for Mac. The project system has had to deliver an immense amount of scope in a short amount of time, so issues like this which don't prevent someone from using the product aren't given top priority. But it's coming.

@masaeedu My advice would be to try out VS 2017 15.5 Preview 1, which works aside from the following:

  • If you add a new file, the constructs in that file may not be visible to files which use it
  • If you add a new project and add a reference to it from an F#/.NET Core project, you won't get IntelliSense for things you use

These two issues are addressed in #3777 and targeted at the 15.5 release. That said, IntelliSense works fully for .NET Core SDK-based projects in the preview, modulo those two issues.

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