Support modern MSBuild 15 like fsproj

[forki]

I have a project with MSBuild 15 see
https://github.com/fable-compiler/fable-suave-scaffold/blob/master/src/Server/Server.fsproj and works perfectly in ionide. Visual Studio 2017 RC says it is not supported.

@cartermp @KevinRansom @enricosada what's the plan for this?

[KevinRansom]

@forki -- the dotnet sdk team are creating templates for F# VS and coreclr.

[forki]

We don't need templates. We need vs to load fsproj - or what am I missing? Am 24.01.2017 8:14 nachm. schrieb "Kevin Ransom (msft)" < [email protected]>:

…

@forki <https://github.com/forki> -- the dotnet sdk team are creating templates for F# VS and coreclr. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2316 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgNHXdVdtC4HLBpM6O8GhYedoG4WZCks5rVk14gaJpZM4LskAL> .

[forki]

FTR: my sample project has absolutely valid fsproj according to dotnetcore and MSBuild. It works absolutely nice with paket integration and ionide understands everything correctly.
TBH we currently push a similar thing to azure about 5 to 10 times a day.

[KevinRansom]

Sounds great ... looks like it's using the new dotnet SDK ... perhaps you can chat with them about what is missing ...

@enricosada might also be able to point you in the right direction.

[forki]

who is them?

[cartermp]

@KevinRansom just to clarify the scenario:

1. I create an MSBuild15-based F# project with the .NET CLI.
2. I attempt to open this project in Visual Studio
3. It fails, because we do not recognize MSBuild15 fsprojs

I'm not sure this is a CLI or SDK concern; I think this is squarely our problem to solve. As it stands, there is no way to open an F# project using the MSBuild15 fsproj in VS 2017. This is a bad situation because it means that you're locked out of anything .NET Core or .NET Standard for F# in VS 2017. This is what I get on the build with Brett's insertion:

[forki]

Thanks @cartermp - started to completely question myself.

[forki]

I think the generated fsproj is fine dotnetcli is doing the right thing thanks to @enricosada. It's "just" VS is rejecting it. So it's definitely a VF# concern.

[KevinRansom]

@cartermp @forki,

Visual Studio is apparently not yet shipping with an SDK that installs enrico's sdk additions. I am looking at a build from the latest rtm branch.

I will follow up with the DOTNET SDK team directly, or someone can follow up with them on the dotnet cli repo. Piotr is in a one on one and then shiproom right now otherwise I would have a definitive answer.

Kevin

[enricosada]

@KevinRansom preview4 already works, What's needed always ship with sdk, after preview3 are just enhancement and cleanups. Also preview3 was working.
See my PR #2250 there there is also an example https://github.com/enricosada/visualfsharp/blob/use_net_core_sdk/examples/dotnetcoresdk/simple/console/ConsoleApp.fsproj who use FscTask too instead of dotnet-compile-fsc

AFAIK vs should

• use Roslyn-project-system so we get all vs ui stuff (treeview etc)
• I think we should add an FSharp capability (I can add that in the sdk target files, so is added for every fsproj, like the other props), that add the and initialize the languageservice parsing the compiler args from fsproj (similar on how now works) so intellisense works.

How vscode works now? How can have intellisense? On build a compile-fsc.rsp is generated who is the response file use for fsc, and ionide read that to initialize the FCS.
Now we can use FscTask (my pr) so compiler args gathering should change a bit (no response file).

If you want to try latest version with preview4, see my pr.

[enricosada]

@KevinRansom what sdk version is used? Becuase fsproj works with all msbuild based preview3,4 and new rc.
Based on sdk version I can give you right templates (or just do dotnet new).

If we know a valid c# template is also easy to modify to be an f# one, changes are minimal.

I hope to have an installed VS2017 RC soon, to try it.

[KevinRansom]

@ enrico so ...
C# is not helpful in this case, because it is supported in the box. I know that they intend to ship your modifications in the box, which will make this template fine. However ... it's not there yet.

Moving the project system to CPS should now be orthogonal. The "joy" of moving back to msbuild based projects means that our current project system should work reasonably well.

As I said I will chat with Piotr and find out why your stuff didn't yet ship. And see if there are some modifications we can propose to the templates.

Kevin

[enricosada]

@KevinRansom about c# I mean seeing the template can show what version of f# template use. In Preview3 for example The f# is just an additional normal PackageReference, so nothing ship with sdk.
Anyway easier wait Piotr

About cps/Roslyn yes is orthogonal, but maybe we can start work on that on master branch, more work becuase need to be implemented, but less work to adapt current code to msbuild.
For example current project system reorder fsproj items on save, no multi fw support, reference but no PackageReference etc.
with Roslyn workspaces already implemented we have a good starting point. Lots of possible PR :)

[KevinRansom]

@enricosada

It seems to me that Goal 1 should be that VS can load a dotnet/cli fsharp template so that we can edit the source. Since we are now using msbuild that should not be too bad a problem to solve.

Most of the project file editing would not have UI because we aren't yet on CPS but we should be able to add --- move, rename and remove F# source files. References will be problematic because they are quite different now and moving to CPS will help address that.

It seems that we are not at Goal 1 - Piotr on DotnetCLI and Daniel on the MSBuild team tells me that your SDK project is included in box for dotnet cli, but not included inbox for VS.

However, we should be able to author an F# template that doesn't use the SDK wiring which can be loaded into the F# Project System as is. For sure the current templates do not do so.

[vasily-kirichenko]

Any progress on this? A month has passed. Could you be more clear where people can click New -> F# -> .NET Core console application and it will work, including debugging? Are we waiting until @enricosada has finished something? MSBuild team? Other people?

[enricosada]

Are we waiting until @enricosada has finished something

@vasily-kirichenko i have nothing more to do for f# in .net core sdk 1.0 and the new fsproj afaik.
From command line all cli commands works (based on latest fsc released by vf# team), and everything is msbuild based (FSharp.Build.dll). Just minor bugfixes/improvement left, but can be done later (already logged in https://github.com/dotnet/netcorecli-fsc/issues ).
I need to do some work for community based FSAC (like vscode) to reenable intellisense, but is not related to VS.
Debugging in vscode already works too because the portable pdb work really well (thx about that @KevinRansom ) in my local tests with vscode debugger.

I added f# templates to dotnet new and these templates are imported as VS templates, for c# at least (used in New-> C#->.NET Core), but afaik are not going in for VS rtm (and is ok, because will not work).

About intellisense/projectsystem/debug/etc in VS dunno, i'll try to work on it, but on the long term roslyn-project-system based option, and later after rtm.

[enricosada]

@vasily-kirichenko some wip by kevin about this in #2482

[vasily-kirichenko]

@enricosada and I were trying to make it work. Results (VS RC4 + OSS VSIX built from current master):

• Install .NET Core SDK 1.0 rc4 from here https://github.com/dotnet/core/blob/master/release-notes/rc4-download.md
• Copy c:\Program Files\dotnet\sdk\1.0.0-rc4-004771\Sdks\FSharp.NET.Sdk\ to c:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Sdks\ (it should be done automatically by whom?)
• dotnet new console -lang f#
• It generates wrong fsproj, we should grab the proper one from here https://github.com/dotnet/netcorecli-fsc/blob/master/examples/rc4/console/console.fsproj

<Project Sdk="FSharp.NET.Sdk;Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp1.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <Compile Include="Program.fs" />
  </ItemGroup>

  <ItemGroup>
    <PackageReference Include="FSharp.NET.Sdk" Version="1.0.*" PrivateAssets="All" />
    <PackageReference Include="FSharp.Core" Version="4.1.*" />
  </ItemGroup>

</Project>

• Try to load it in VS
• We expect <ProjectGuid> tag in fsproj and crash here https://github.com/Microsoft/visualfsharp/blob/master/vsintegration/src/FSharp.Editor/Common/LanguageService.fs#L296 if it does not exist (site.ProjectGuid is null). After adding the tag the project is successfully loaded.
• Build from VS does not work until we added the following (it seems to be ralated to the OSS VSIX, so it may work on stock / Full VSIX ootb):

<DontRunFscWithDotnet>true</DontRunFscWithDotnet>
<FscToolExe>fsc.exe</FscToolExe>
<FscToolPath>e:\github\visualfsharp\release\net40\bin\</FscToolPath>

and we had to copy a bunch of assemblies from related packages to c:\Users\<user>\.nuget\packages\fsharp.compiler.tools\4.1.0\build\netcoreapp1.0\ so that it looks as following:

15-Feb-17  15:26               490 default.win32manifest
15-Feb-17  15:26             3,633 fsc.deps.json
15-Feb-17  15:26            25,744 fsc.dll
15-Feb-17  15:26               118 fsc.runtimeconfig.json
28-Feb-17  15:23            58,880 FSharp.Build.dll
28-Feb-17  15:23            69,120 FSharp.Build.pdb
28-Feb-17  15:23             1,465 FSharp.Build.xml
28-Feb-17  15:24        12,011,520 FSharp.Compiler.dll
28-Feb-17  15:24        13,129,216 FSharp.Compiler.pdb
28-Feb-17  15:24         1,050,766 FSharp.Compiler.xml
28-Feb-17  15:23         1,619,968 FSharp.Core.dll
28-Feb-17  15:23           430,744 FSharp.Core.optdata
28-Feb-17  15:23         2,731,520 FSharp.Core.pdb
28-Feb-17  15:23           561,214 FSharp.Core.sigdata
28-Feb-17  15:23           721,710 FSharp.Core.xml
15-Feb-17  15:26            25,040 Microsoft.DiaSymReader.dll
15-Feb-17  15:26            92,640 Microsoft.DiaSymReader.PortablePdb.dll
28-Feb-17  14:27    <DIR>          runtimes
11-Jun-16  23:13            21,704 System.AppContext.dll
11-Jun-16  23:13            22,184 System.IO.dll
11-Jun-16  23:14            22,728 System.Reflection.dll
15-Feb-17  15:26           432,872 System.Reflection.Metadata.dll
11-Jun-16  23:14            29,880 System.Runtime.dll
11-Jun-16  23:14            33,000 System.Runtime.Extensions.dll
15-Feb-17  15:26            47,304 System.ValueTuple.dll

and we had to copy FSharp.Core.dll/opdata/sigdata, FSharp.Compiler.dll and FSharp.Build.dll from e:\github\visualfsharp\release\net40\bin\ to c:\Users\<user>\.nuget\packages\fsharp.compiler.tools\4.1.0\build\netcoreapp1.0\, because it crashes with MethodNotFoundException.

After all these hacks:

• The project is loaded to VS
• It can be built inside VS
• It can be debugged by attaching to process
• All IDE features work

What does not work:

• F5 does not start debugging because it cannot find *.exe file to run:

.NET Core console apps are DLLs which must be launched with dotnet run <dll> (@enricosada am I right?), so we should change something in ProjectSystem.Base or ProjectSystem I think.

• There are phantom nodes in Solution Explorer:

which are from

<ItemGroup>
    <PackageReference Include="FSharp.NET.Sdk" Version="1.0.*" PrivateAssets="All" />
    <PackageReference Include="FSharp.Core" Version="4.1.*" />
</ItemGroup>

I think they should be moved to References node or a new Packages node.

Debugging:

[slang25]

Love seeing progress on this 😃

.NET Core console apps should be launched with just dotnet, like dotnet myapp.dll, dotnet run is for when you are in the project folder and want the cli to take care of figuring out if it needs building etc.

[vasily-kirichenko]

@slang25 thanks :)

[enricosada]

Added dotnet/netcorecli-fsc#87 to locate dotnet, so netcore fsc will work (no need to override with .net full version of fsc)

[enricosada]

I'll add some todo there, but should be a checklist in another meta issue (not this one) about "modify current project system to handle new fsproj", with all open points, issues found.
Maybe is better if you @vasily-kirichenko open it, so you can update the description with status/checklist later? @KevinRansom can already update that as admin.

• fix location of dotnet , ref dotnet location when fsproj is called from msbuild .net full netcorecli-fsc#87
• Manage projectguid (used also for project reference in the vf# project system afaik). Maybe read it from solution? because a solution file always exists, and guid there exists.
• Special msbuild items (like PackageReference, DotnetCliTool) as nodes, filter out (fast) or add new node types (useful?)
• make it readonly from ui. On save current vf# code will change fsproj and afaik that is risky. ihmo better tell everyone to manually edit fsproj.
• use netcoreapp1.0 fsc or net40 fsc when building inside VS? as default?
• use FSharp.Build.dll for net40 when building inside VS, but i think the current packaged in FSharp.Compiler.Tools has signing (read internal visible) issues?
• propose dotnet restore at opening of project? because nothing works if is not restored already before open.
• check build, ctrl-f5 run for netcoreapp
• check build, ctrl-f5 run for net461 app
• how crossgen (multiple target framework will work) will work? what is the current target fw executed by VS? a combo somewhere?
• write a wiki with existing workarounds (like restore before load solution) may be enough for some things

[vasily-kirichenko]

Add file dialog shows no templates:

[vasily-kirichenko]

make it readonly from ui. On save current vf# code will change fsproj and afaik that is risky. ihmo better tell everyone to manually edit fsproj.

I think it's not risky. That's the change VS made after warning level was changed via UI:

look pretty good.

[enricosada]

@vasily-kirichenko good, but that Condition is not what it's used normally in new fsproj. i mean the |$(Platform). If we can remove or change that condition is better

@vasily-kirichenko i am more scared about file moves/deleted/added, or references added

Add file dialog shows no templates:

that's probably because the fsproj has no f# project guid (is not used anymore in new msbuild, because all csproj is using cps capabilities instead). we can add that, but maybe is better not do so? (ref scared about add files)

[vasily-kirichenko]

@enricosada

• Move up / down works OK.
• Add does not work, see above.
• Delete works OK.

So I think project modifying and saving inside VS is not the main concern right now.

[vasily-kirichenko]

Trying to add a reference:

[enricosada]

After the really promising and unexpected work in dotnet/project-system#1670 to enable F# with CPS and new roslyn project system, ihmo is useless to do work to patch the old project system. @KevinRansom what do you think?

[xperiandri]

How can this process be speed up? Which help is required?

[enricosada]

@xperiandri see comments in dotnet/project-system#1670
work is pratically finish that PR.
with FSharp.NET.Sdk 1.0.2 the msbuild fsc task should be ok

[xperiandri]

That is excellent!
How this affects ability to use it in Visual Studio 2017 soon?
Will Visual F# tools update just support it or it will require a new build of Visual Studio 2017 Update Preview to try this?

[GiorgioG]

@cartermp any update on when we might see a usable (even if beta) release for VS2017?

[vasily-kirichenko]

AFAIK, July is a super optimistic estimate.

[cartermp]

@GiorgioG Current target is July. Issues tracking it are here: https://github.com/dotnet/project-system/issues?q=is%3Aopen+is%3Aissue+label%3AArea-F%23

The "15.3" milestone represents the third update to VS 2017, which is likely to be around July.

[stanuku]

I apologize if I missed something, but here is my issue/question:

I created a FSharp project with dotnet new mvc -lang F#. Opening it in VS 2017 fails with the error (same as the image in @cartermp's post https://cloud.githubusercontent.com/assets/6309070/22265426/d4ca9dc2-e230-11e6-81dd-380b3de14828.PNG)

From command line:

• MSBuild myproj.fsproj fails with same error.
• dotnet build myproj.fsproj builds fine.

My understanding is that dotnet CLI uses MSBuild 15 engine (APIs) under the covers, so why does dotnet build work and not MSBuild?

My environment:

• VS 2017 15.2 (26430.6)
• .NET Core 1.1, SDK 1.0.4
• MSBuild 15.1.1012.6693

Thanks

[enricosada]

@stanuku because VS msbuild doesnt include FSharp.NET.Sdk in the Sdks msbuild cache. Otherwise works the same in mono, VS, dotnetcli

See #2928 (comment)

If you copy %PATH_OF_DOTNET_EXE%\sdk\1.0.4\Sdks\FSharp.NET.Sdk into C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Sdks\FSharp.NET.Sdk\ will work in msbuild.exe (more info in https://github.com/dotnet/netcorecli-fsc/releases/tag/v1.0.3 )

But will not work in VS, because VS doesnt yet understand new project format ( more info in #3069 ) expected in July update

[stanuku]

@enricosada: Ok, understood. Thank you and please keep up the great work on F# front.

[stanuku]

@enricosada I've copied the F# SDK to the MSBuild cache and when I opened the .fsproj I got this error:

Please let me know if I should wait till the next VS 2017 update or if there is a work around for this error. or post this error/issue in some other repo?

[enricosada]

@stanuku while copying sdk directory will make msbuild work from command line, is not enough for VS VF# extension, who need work for support the new project format (is a big change, but near completion).

See roadmap, need to wait until VS 2017 15.3 update at least (july timeframe)

[cartermp]

Closing this now, as these projects load with 15.3. The current way to use them:

• Download VS 2017 Update 3 Preview 3 (or a further preview if it's released and you're reading this)
• Download the latest CLI/SDK from here: https://github.com/dotnet/cli/tree/release/2.0.0#installers-and-binaries

(Yes, the .NET SDK is independent of VS. You will also need this to get .NET Core 2.0 support in VS 2017 Update 3 Previews).

There is a small amount of remaining work left in our own language service to no longer depend on IProjectSite. This the root cause behind #3260 and #3266. Work to support file ordering, and any other project system-specific F# issues is being tracked here: https://github.com/dotnet/project-system/issues?q=is%3Aopen+is%3Aissue+label%3AArea-F%23

[xperiandri]

Should it be Preview 3 CLI?

[cartermp]

Nope, the one linked above is the one to use. There is no Preview 3 of the CLI (at the time of writing this). There is also no affinity between the VS version and CLI version. They have been designed so that you can update the .NET Core CLI and SDK out of band from VS.

[xperiandri]

@cartermp, thanks. Here is an issue dotnet/project-system#2534

[Thorium]

Should the files be in alphabetical order?
Also FSharp CoreApp 2.0 project's intellisense seems not to work with VS2017 and latest daily release of the tools.

[cartermp]

@Thorium Most issues are being tracked here: https://github.com/dotnet/project-system/issues?q=is%3Aopen+is%3Aissue+label%3AArea-F%23

If you're using 15.5, then I suspect your issues with IntelliSense are due to #3653, which enables project-to-project references and fixes a bug where adding files results in IntelliSense issues.

In 15.3, the projects will load but they're not fully supported at all.

Also, the alphabetical issue is tracked in this repo, along with a few other issues: https://github.com/dotnet/project-system/issues?q=is%3Aopen+is%3Aissue+label%3AArea-F%23

[Thorium]

Thanks, I'm using 15.3 as there is no official 15.5 yet. Let's hope it won't vanish from the release version of 15.5 like F# features of Visual Studio often tend to.