fsc doesn't work on platforms with only net core 1.1 installed

[eerhardt]

There are 3 platforms that came online between .net core 1.0 and .net core 1.1:

1. ubuntu.16.10-x64
2. fedora.24-x64
3. opensuse.42.1-x64

.NET Core 1.0 runtime doesn't support these platforms, however we need to get the .NET Core SDK working on these platforms.

The F# compiler fsc only supports .NET Core 1.0 currently. In it's NuGet package it has a runtimeconfig.json that explicitly says it needs to run on 1.0.1 shared framework. But on these 3 platforms there can't exist a 1.0.x shared framework. Thus F# can't be used on these platforms.

[enricosada]

thx a lot @eerhardt

Is ok to fix it like that?

• I'll add an netcoreapp1.1 fsc in FSharp.Compiler.Tools package, so both are avaiable.
• the target will run fsc with the .net core 1.0 or 1.1 runtime based on ??

@eerhardt how i can choose what runtime to run fsc? i found these msbuild props:

• MSBuildRuntimeType = Core
• MicrosoftNETBuildTasksTFM = netcoreapp1.0

Is ok to use these? who can i ask about it?

[eerhardt]

MicrosoftNETBuildTasksTFM comes from the dotnet/sdk, and is really only supposed to be used by it internally to build up where it should find its own tasks. See https://github.com/dotnet/sdk/blob/master/src/Tasks/Microsoft.NET.Build.Tasks/build/Microsoft.NET.Sdk.Common.targets#L19-L22. It should probably start with an _ to tell people it is private.

MSBuildRuntimeType = Core is OK to use to know that MSBuild is running on .NET Core. But you can't tell whether it is running on 1.0 or 1.1. @rainersigwald @jeffkl @nguerrera @dsplaisted @piotrpMSFT - any ideas on how to tell what version of .NET Core that MSBuild is running on?

@enricosada - One thought: since the CLI itself runs on 1.1, if you are being invoked by the CLI, it is guaranteed to have the 1.1 runtime installed. So you could default to 1.1, and then give an "escape hatch" MSBuild property that a user could set to tell you to use a different runtime, if they absolutely needed to use 1.0.

[enricosada]

@eerhardt seems a good plan, i can default to runtime 1.1 (when i have fsc for it :D) for sdk 1.0, because sdk contains both anyway.

"escape hatch" just for f# is not that bad too, but having it somewhere from sdk/msbuild is better is possible. less hacks
Like know what's the host of msbuild, ref dotnet/msbuild#1669

[rainersigwald]

I'm not sure knowing what the host is would be sufficient--what about a theoretical future dotnet that's running on shared framework 87?

Is there an easy way for running code to tell what runtime it's on? We could in the future add a property MSBuildRuntimeVersion, but I don't know how we'd compute that.

Full framework MSBuild does have FrameworkVersion = v4.0.30319, but that's not enough to determine a real version, which is confusing. Hopefully we can do better (or avoid the need) in Core.

[eerhardt]

We had a similar question on email recently, and the email discussion was pointed to https://github.com/dotnet/corefx/issues/12737 as tracking some of the information.

So I'm thinking knowing whether you are running on 1.0, 1.1, or 2.0 of .NET Core is a fairly useful thing across a multiple scenarios.

[dsplaisted]

Is there any reason for the F# compiler to run on .NET Core 1.0? Would it be OK to just run on .NET Core 1.1 everywhere?

It looks like we will probably be recommending people target 1.1 over 1.0 in general: dotnet/sdk#893

[enricosada]

@dsplaisted none at all. was just built and packaged as 1.0 in https://www.nuget.org/packages/Microsoft.FSharp.Compiler.netcore/

added dotnet/fsharp#2502 to add .net core 1.1 fsc so can be added later (need just an fsharp.net.sdk update, no templates changes)

[enricosada]

Closing in favor of sdk 2.0, ref #91 (comment)