Project-system: F# support

[enricosada]

Maybe it's not the right place to ask, but i have seen comment in .net blog to give feedback here.

Maybe it's already in roadmap, or discussed, i tried to search this repo/visualfsharp/internet, but my google foo failed so i opened this issue.

I really liked the idea in comments about having a single .netproj ( like old xproj/project.json ) with a simple compilerName to drive c# vs vb vs f# vs newdotnetlang, was extensible and simple.
For example i can now open a xproj f# and works (not intellisense) but everything else (publish, etc) is ok. Also .netproj extension name is really awesome.
So a shared project file plus some extensibility works, so where to extend?

I see in #40 the cleanup of csproj continue, that's great, moving default in language targerts, plus and some comments from @davkean about naked .proj

and final line in csprj is about

  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />

That said, with current cps requirement, it's possible to make the .Managed read an msbuild property and use the required classes ( .CSharp, .VisualBasic ) instead of subclass? And file extension with old proj? So all .csproj / .vbproj are really the same project. I know cps capabilities help to share, but how that intesect with having different proj? :confused:
With old system was really easy (and bad for f# and other proj ) to create a special item/feature for a specific project flavor. i understand cps help a lot about that with capabilities.

If not possible, this repo is the right place to subclass for adding the required host-agnostic and vs layer .FSharp project? inheriting from .Managed?
With .net cli ( now .net core sdk :smile: ) having all the glue code in a single repo helped to have it aligned, was easier with the code changing a lot, until the good extensibility was in place with .net sdk tools ( dotnet-compile-{compilerName} ) and the language specialization is extracted.

If it's not there the place np, but to untangle things, it's possibile to have a pointer what are the missing pieces? f# lack a roslyn workspace?

I'd like to help implement what's missing, to fully support F#

[davkean]

A couple of comments:

1) We don't have an intention of inventing a language-agnostic extension. It's unclear to me - given we already have csproj, vbproj and fsproj - what we would gain from that. Can you expand on what problems this would solve for you?

However, in saying that, CPS behavior and features are not driven off extensions - a 3rd party could add a "netproj" add the required "capabilities" to the project file or targets and give it the same C# or VB behavior that csproj/vbproj has. Whether to use XXX.CSharp.dll or XXX.VisualBasic.dll is effectively driven off a "capability" - ie:

<ItemGroup>
    <ProjectCapability Include="CSharp"/>
</ItemGroup>

Causes XXX.CSharp.dll to be loaded and its of its components (marked with this capability) to be loaded and used.

2) We are thinking about F# as we bring up the new project system, the discussion for this is being tracked over here: https://github.com/Microsoft/visualfsharp/issues/1193. It's still very early, and there some large work items that are being worked on at the moment, such as F# on the Roslyn workspace model, that will make this transition somewhat easier.

[enricosada]

1) We don't have an intention of inventing a language-agnostic extension. It's unclear to me - given we already have csproj, vbproj and fsproj - what we would gain from that

Maybe now with cps capabilities it's easier, but for example:

• f# lack "show all files", "folders", "add some items", etc.
• nodejs/ptvs use a newer version of same project system, and has these.

up to now, each project system need to implement a same basic functionality. and extensions targeted some flavor or specific interfaces/csproj, for no reason.
i think cps provide these features declaring capabilities, and that's awesome, but what i was trying to say is: all .net prj (cs,vb,fs) can share a lot more than the other proj ( cs and fs VS cs and nodejs ).
because the build is msbuild based, other actions can be shared like publish, packaging, deploy, debug, resx, clickonce, settings, app.config, etc.
these can be implemented as capabilities and used by f# project system, i think, but vb get the same features as c# also because the base class .Managed is in common and roslyn based.

The really good part about .net core sdk ihmo was the multilanguage support designed with some specific extensions point, so a lot of functionalities is shared for free, and simply works. Smaller scope for sure than a whole ide support, but was ok.

But having different implementation is ok, just asking where to expect extensions points (cps capabilities vs roslyn features)

2) We are thinking about F# as we bring up the new project system, the discussion for this is being tracked over ...

I have seen that issue, but this is the repo implementing the new project system, so i am asking for info to help boostrap the f# support, because i think you @davkean and the team of this repo know better what's need to be implemented next.
Having a list of issue as starting point and a bit can help a lot, because f# community ( i want to try do it ) can help meanwhile visualfsharp team continue the with the coreclr and the other issues.

But atm is really hard to help because we dont know the target, and lot of code (cps, project system, msbuild changes) is new and wip.
That's ok, with some info ( a gitter/slack chat maybe, some links, a guidance to the right direction ) i think it's possibile to try to boostrap the f# support, the f# community is smaller than c# but really active.

[KevinRansom]

@enricosada

Thanks to the demise of project.json it is no longer vital that the F# project system is implemented using CPS, which, is very convenient for us because the CPS team are currently swamped and not in a position to enable the file-ordering changes that we need. Fortunately we can rely on our existing project system code for DEV 15 RTM because msbuild will be updated to deal with coreclr based projects.

Thank goodness for that. Our long term aim is to have CPS project system support for F# because that will give us access to all of the workspace goodness, but for now it is not an absolute requirement.

And so ... for the near term CPS is not a priority for us.

I think shortly after RTM we will revisit CPS and figure out what is necessary for us to do in terms of the F# project system, however, right now, it's just not something we are in a position to move forward with.

I hope this helps, I know how frustrating it is, but the recent reset has had a bunch of effects on priorities that we didn't anticipate.

Kevin
@srivatsn @otawfik-ms @davkean

[baronfel]

as an aside, would the migration of VisualFSharp to the roslyn workspace APIs involve work that would enable F# code to be easily plugged into existing microsoft tooling like docfx? This issue seems to suggest that there is work to be done on that front, and I worry about f# reception when tooling like this seems to more and more assume things that F# doesn't have yet. Is there some amount of community involvement that could address this gap at all?

[davkean]

I'm not sure - but docfx seem to be using the symbol layer, which F# won't be implementing.

[davkean]

We've added support for F# in 15.5.

[dsyme]

🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉