Support new sdk, the new fsproj of .NET Core Sdk

[enricosada]

An important note: the .NET Core Sdk can build all target frameworks (net, netcore, pcl), so both .NET Framework and .NET Core projects.
New fsproj is going to be the replacement for old fsproj, because is based on the new .NET Sdk
the msbuild from mono, .net full can run same project too.

FSC and related consumer (FSAC based ide) should support the new .NET Sdk, so for f# the new fsproj.
Ignore project.json because is dead, and there is a clean project.json -> fsproj migration, same features.

The workflow is the same, msbuild call Build target, who invoke fsc using FscTask from FSharp.Build.dll
The rest of sdk (Microsoft.NET.Sdk) is shared with the rest of .net (c#, vb)
Some notable changes from old fsproj atm: fsc is inside FSharp.Compiler.Tools, the target files in FSharp.NET.Sdk.

I miss some info.

Starting from the basics. What FCS need? What editors need? Previously that was done using project cracker, but maybe we can fix that without duplicate code/hacks.
My idea is also reuse code/lib from sdk/c#/omnisharp for common info (like compile items, etc), without hack/fork these in project cracker.

What FCS need?

• 1 get fsc arguments.
• 2 get projectreference list (??)
• 3 ??

What ide/editors need?

• A compile items
• B all nont compile items to show (None etc)
• C target frameworks (can be more than once)
• D ??

/cc @tpetricek @dsyme @7sharp9 @latkin @vladima FCS team
/cc @rneatherway emacs
/cc @kjnilsson vim
/cc @guillermooo sublime
/cc @KevinRansom @cartermp vs
/cc @nosami @mrward vs on mac
/cc @Krzysztof-Cieslak ionide vscode/atom
/cc @alfonsogarciacaro fable

(please add who is missing) and github teams maybe? :D

Some possibile solution

• 1 i have a possibile solution in read fsc args from new fsproj #707

[enricosada]

added a proposed solution on how to replace projectcracker for fsc args #707

[enricosada]

Given now with #707 i can read the fscargs and p2p refs, what's missing there?

How to package it? more properties are needed?

[KevinRansom]

@enricosada
With the CPS work that is about to get moving in earnest, I believe that parts of the fsharp.sdk at least the targets and props are going to move into the dotnetsdk. which will mean it will always get deployed with the dotnet cli and VS. Which is a blessing because the IDE experience will be vastly improved by having these items immediately available on project new.

I'm not sure what that all means or how what the right distribution is.

Please work with @srivatsn and @brettfo and @piotrpMSFT to work out the correct distribution.

[srivatsn]

The actual language targets don't live in the dotnet/SDK repo. The only targets in the SDK repo are about the app models (for netcore generating deps.json for eg) or setting defaults for frameworks. The actual language targets should live elsewhere (preferably closer to the compiler\build task). For C# for eg, the targets file that has CoreCompile lives in the roslyn repo next to the csc task itself and the SDK.targets file in the Dotnet/SDK repo just imports it with a relative path in MSBuild. If we can standardize on where the FSharp.targets are deployed relative to msbuild (which we already have for projects created in VS atleast), then the SDK.targets can add a check for .fsproj and pull in the FSharp.targets similar to how it pulls in the csharp.targets.

I don't fully understand all the places fsproj is used but in my mind, there should be one fsharp.targets instead of the two it looks like we have today (VF# repo and the fSharp.sdk) - should we be consolidating to one place or another?

[cloudRoutine]

Using the path relative to msbuild in VS has been a stumbling point for a bunch of people who didn't realize VS2017 changed the path structure relative to older versions. I've had to change the targets for almost every F# OSS project I work on.

    <When Condition="$(TargetFSharpCoreVersion) &gt;= 4.3.0.0 AND $(TargetFSharpCoreVersion) &lt; 4.3.1.0 ">
      <PropertyGroup>
        <FSharpTargetsPath>$(MSBuildProgramFiles32)\Microsoft SDKs\F#\3.0\Framework\v4.0\Microsoft.FSharp.Targets</FSharpTargetsPath>
      </PropertyGroup>
    </When>
    <When Condition="$(TargetFSharpCoreVersion) &gt;= 4.3.1.0 AND $(TargetFSharpCoreVersion) &lt; 4.4.0.0 ">
      <PropertyGroup>
        <FSharpTargetsPath>$(MSBuildProgramFiles32)\Microsoft SDKs\F#\3.1\Framework\v4.0\Microsoft.FSharp.Targets</FSharpTargetsPath>
      </PropertyGroup>
    </When>
    <When Condition="$(TargetFSharpCoreVersion) &gt;= 4.4.0.0 AND $(TargetFSharpCoreVersion) &lt; 4.4.1.0 ">
      <PropertyGroup>
        <FSharpTargetsPath>$(MSBuildProgramFiles32)\Microsoft SDKs\F#\4.0\Framework\v4.0\Microsoft.FSharp.Targets</FSharpTargetsPath>
      </PropertyGroup>
    </When>
    <Otherwise>
      <PropertyGroup>
        <FSharpTargetsPath>$(MSBuildProgramFiles32)\Microsoft SDKs\F#\4.1\Framework\v4.0\Microsoft.FSharp.Targets</FSharpTargetsPath>
      </PropertyGroup>
    </Otherwise>
  </Choose>
  <Import Project="$(FSharpTargetsPath)" Condition="Exists('$(FSharpTargetsPath)')" />

Has worked decently for me although for some people XBuild doesn't seem to support <= in project files, but they can use msbuild now so that's not a huge issue.

Why not set Environment variabales during the F# SDK installation and use that to find the targets like VS does?

FSharpSDKs="C:\Program Files (x86)\Microsoft SDKs\F#"

or maybe set an envar per compiler version installation that way it'll be set to wherever the user decides and most of the guesswork will be out of the picture.

plus the envar can be aliased over in the process before the build starts if a different target set or a custom compiler build is needed for w/e reason.

[dsyme]

@enricosada @ncave

Can someone give me a hand here please? I'd really, really appreciate help in getting this project to match the latest version of the .NET Core tooling - at least so it builds out of the box when that tooling is installed on the machine, and creates a good nuget package.

• Currently this project requires the old preview2-1-003177 version of the .NET Core tooling to even build build.cmd All.NetCore. (If you have a later version installed then the command dotnet restore -v Information fails while running build.cmd All.NetCore). This is wrong since most people now have a later version of the tooling installed.

• The AppVeyory CI machine configuration seems to have the old version of the .NET Core tooling preview2-1-003177 installed by default, which is why AppVeyor is able to build things for .NET Core. However fewer and fewer developer machines have this installed. This is a major problem but maybe there's a way to tell AppVeyor to acquire the latest version of the tooling?

• I don't understand enough about the old/new versions of the .NET Core tooling to make this change easily. Nor do I understand how we are expected to check for the right version and acquire it if necessary.

• I don't really care about ProjectCracker etc understanding the new project format just yet - i just want this project to build and test cleanly both on developer machines and on AppVeyor CI.

If someone who is up-to-date with .NET Core tooling coud update this project please I'd be hugely grateful....

thanks
don

[enricosada]

there are two separate stuff:

• upgrade this repo to use nwe fsproj and .net core sdk 1.0 (-> Use new fsproj, replace project.json #700)
• make intellisense work for ide (this issue).

I was working on this, on intellisense (with https://github.com/enricosada/dotnet-proj-info is pratically done, need refactor as lib) but i can do this migration now that 1.0 is out, if you think will unblock more.

i'll add more comments in #700

[dsyme]

@enricosada Cool, thanks. Yes let's discuss the repo upgrade in #700

[cloudRoutine]

@dsyme since the packages are getting cleaned up could this be ironed out at the same time #675 ?

The version on appveyor doesn't really matter, most netcore projects specify the version they want and download and use it instead of the one on the CI. I can get started on this

[enricosada]

Added a working example using FSAC (called by vscode) in ionide/FsAutoComplete#53

There are also samples ready to use, see PR.

Now just restore Ian needed, project to project works, and in vscode also intellisense and F5 debug.

The integration to read fsproj (props/fsc args/p2p) exists as cli console app or library (lib is used by FSAC)

Feedback welcome!

[enricosada]

as a note on progress with PR ionide/FsAutoComplete#53 , if someone want to review it (please! contains link to ready to use sample project too):

Is just FSAC code, so should work for everyone.

• intellisense works (from p2p project reference or normal package references)
• f5 -> debug ok! (but coreclr debugger is a competitive advantage, so mileage may vary)
• just a restore (like dotnet restore) is required, because need to restore FSharp.NET.Sdk. not build like previous implementation

[enricosada]

An update, released all required components:

• FSharp.Compiler.Tools 4.1.1 for Fsc task (thx @dsyme @KevinRansom)
• FSharp.NET.Sdk 1.0.2 for targets
• Dotnet.ProjInfo 0.5.0 for parse/eval msbuild project

and final FSAC integration (to replace projectcracker) wip in ionide/FsAutoComplete#55

in the PR there are info about how to test (with vscode), but is just FSAC code, so any client will do.
Added also ready to use projects (with packageref, p2p) in https://github.com/enricosada/DotnetNewFsprojTestingSamples