is that a thing?

It's a property used by the Fsc task

should we go the way @enricosada proposes in https://github.com/dotnet/netcorecli-fsc/blob/master/examples/preview3/console/ExampleConsoleApp.fsproj#L6 ?

This is all internal build engineering stuff trying to clear up the legacy, Right now we use MSBuild and Microsoft.DotNet.BuildTools in this repo to build .NET Core stuff. No one else does that except corefx, it's just different

Enrico's stuff is orthogonal - when it's real it will help us to converge

cool thanks for clarification.

As don said, the TargetFramework (and TargetFrameworks ) depends on on .net core sdk msbuild targets.
Atm i pass --targetprofile:netcore flag to fsc (in sdk preview2 too) if target framework is netstandard or netcoreapp ( ref https://github.com/dotnet/netcorecli-fsc/blob/b5dd998bc6d444812c62cbac96eae48078eb77f7/src/dotnet-compile-fsc/Program.cs#L179-L182 )
Maybe that is another thing the FcsTask can infer by itself becased on TargetFramework

@enricosada You should also pass it when compiling up the .NET Portable profiles where System.Runtime is king (everything except the "legacy" profiles like Profile47)

@dsyme thx, i'll do.
i was asking usage times ago, adding ref to dotnet/netcorecli-fsc#2 for remeber to do it

@enricosada great