fsharp / fslang-design

RFCs and docs related to the F# language design process, see https://github.com/fsharp/fslang-suggestions to submit ideas
519 stars 143 forks source link

Simplest Template for: F# RFC FS-1032 - Support for F# in the dotnet sdk #193

Closed KevinRansom closed 7 years ago

KevinRansom commented 7 years ago

https://github.com/fsharp/fslang-design/blob/master/tooling/FST-1002-fsharp-in-dotnet-sdk.md

The basic template for a console app looks like:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.0</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <Compile Include="Program.fs" />
  </ItemGroup>
</Project>

Modify the TargetFramework tag to deal with different frameworks: valid values include but are not limited to:

netcoreapp1.0
netstandard1.6
net45
net46
net461
net47

TargetFrameworks The dotnetsdk allows a project to produce multiple targets use the target frameworks tag

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFrameworks>net45;net46;net461;net462;netcoreapp1.0;netcoreapp2.0</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <Compile Include="Program.fs" />
  </ItemGroup>
</Project>

Notes: Portable Libraries: TBD: currently the SDK doesn't support portable library targets. Use the legacy project format for these. Really unfortunately in FSharp.Core we rely on some APIs that require high versions of netstandard (1.6) -- so we will probably have to produce a new netstandard version of FSharp.Core for portability ... probably netstandard 1.3.

System.ValueTuple Reference It is not necessary to include System.ValueTuple reference. Thje reason is that a package reference is automagically added during the build.

This is valuable because System.ValueTuple is kind of confusing ...

You need to reference it for net45,net46, net461, net462, net47 and coreapp1.+ and netstandard 1.6. You don't need to reference it for net471 and up or netcoreapp 2.+ or netstandard2.+.

net47 is the most vexing, because the full desktop framework contains the type but the reference assemblies do not contain the type forward.

DisableImplicitSystemValueTupleReference To disable this, because ... reasons ... Use the DisableImplicitSystemValueTupleReference property [true or false]

FSharp.Core reference When building coreclr the framework automagically references the FSharp.Core using a wild card Currently: 1.0.0- Once we have a netcore2.0 fsharp.core package it will likely change to 1.0.0- for netcoreapp1.+ and netstandard1+ and 2.0.0-* for netcoreapp2+ etc.

DisableImplicitFSharpCoreReference To disable automagic fsharp.core reference use the DisableImplicitFSharpCoreReference property [true or false]

FSharpCoreImplicitPackageVersion To change the package version set: the FSharpCoreImplicitPackageVersion to a specific value.

TargetFSharpCorePackageIdentity To use a different nuget package for FSharp.Core.dll use the TargetFSharpCorePackageIdentity property.

TargetFSharpCoreVersion For desktop versions, E.g. those who want to target FSharp.Core.4.3.0.0 e.t.c use the TargetFSharpCoreVersion property. This has no effect on netstandard or netcoreapp target builds.

These proposals are implemented within the VisualFSharp repo in targets we deploy with the compiler, and so will not require coordination with the cli or sdk to implement.

The source files can be found here: https://github.com/Microsoft/visualfsharp/blob/master/src/fsharp/FSharp.Build/Microsoft.FSharp.NetSdk.props and here: https://github.com/Microsoft/visualfsharp/blob/master/src/fsharp/FSharp.Build/Microsoft.FSharp.NetSdk.targets

A console app targeting multiple frameworks and the 4.4.0.0 fsharp.core

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFrameworks>net45;net46;net461;net462;net47</TargetFramework>
    <TargetFSharpCoreVersion>4.4.0.0</TargetFSharpCoreVersion>
  </PropertyGroup>
  <ItemGroup>
    <Compile Include="Program.fs" />
  </ItemGroup>
</Project>
C:\temp\fsharp.builtin>dotnet restore
  Restoring packages for C:\temp\fsharp.builtin\fsharp.builtin.fsproj...
  Generating MSBuild file C:\temp\fsharp.builtin\obj\fsharp.builtin.fsproj.nuget.g.props.
  Generating MSBuild file C:\temp\fsharp.builtin\obj\fsharp.builtin.fsproj.nuget.g.targets.
  Writing lock file to disk. Path: C:\temp\fsharp.builtin\obj\project.assets.json
  Restore completed in 295.17 ms for C:\temp\fsharp.builtin\fsharp.builtin.fsproj.

  NuGet Config files used:
      C:\temp\fsharp.builtin\NuGet.Config
      C:\Users\kevinr\AppData\Roaming\NuGet\NuGet.Config
      C:\Program Files (x86)\NuGet\Config\Microsoft.VisualStudio.Offline.config

  Feeds used:
      https://dotnet.myget.org/F/dotnet-core/api/v3/index.json
      https://api.nuget.org/v3/index.json
      C:\Users\kevinr\.dotnet\NuGetFallbackFolder
      C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\

C:\temp\fsharp.builtin>dotnet build
Microsoft (R) Build Engine version 15.3.117.23532
Copyright (C) Microsoft Corporation. All rights reserved.

  fsharp.builtin -> C:\temp\fsharp.builtin\bin\Debug\net45\fsharp.builtin.exe
  fsharp.builtin -> C:\temp\fsharp.builtin\bin\Debug\net46\fsharp.builtin.exe
  fsharp.builtin -> C:\temp\fsharp.builtin\bin\Debug\net461\fsharp.builtin.exe
  fsharp.builtin -> C:\temp\fsharp.builtin\bin\Debug\net47\fsharp.builtin.exe
  fsharp.builtin -> C:\temp\fsharp.builtin\bin\Debug\net462\fsharp.builtin.exe

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:09.58

C:\temp\fsharp.builtin>

I hope this is satisfactory

Kevin

0x53A commented 7 years ago

@KevinRansom can you please update your post to the actually used properties? It makes an already complex topic slightly more confusing. =)

e.g. https://github.com/Microsoft/visualfsharp/issues/3335#issuecomment-315545434

From what I can see it is

TargetFSharpCorePackageVersion => FSharpCoreImplicitPackageVersion
DisableAutoFSharpCoreReference => DisableImplicitFSharpCoreReference
DisableAutoValueTupleReference => DisableImplicitSystemValueTupleReference
dsyme commented 7 years ago

@0x53A Sorry for the delay here - I will update the post and the RFC with @KevinRansom later today

dsyme commented 7 years ago

I adjusted the issue text, and am closing this because all the content is captured in the RFC (which I have also updated here and there in #226 )