Support for --standalone on .NET Core

[KevinRansom]

Compile a project with --standalone on the coreclr and the compiler crashes.

repro:

1. dotnet new console -lang F#
2. Edit the project file created and add to the propertygroup:
   $(OtherFlags) --standalone
3. dotnet build

Observe the build failure message:

c:\temp\foop>dotnet build
Microsoft (R) Build Engine version 15.5.178.35674 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Restoring packages for c:\temp\foop\foop.fsproj...
  Generating MSBuild file c:\temp\foop\obj\foop.fsproj.nuget.g.props.
  Generating MSBuild file c:\temp\foop\obj\foop.fsproj.nuget.g.targets.
  Restore completed in 845.82 ms for c:\temp\foop\foop.fsproj.
FSC : error FS2014: A problem occurred writing the binary 'c:\temp\foop\obj\Debug\netcoreapp2.0\foop.dll': Error in pass3 for type Program, error: Error in GetMethodRefAsMethodDefIdx for mref = ("PrintFormatLine", "Microsoft.FSharp.Core.ExtraTopLevelOperators"), error: Exception of type 'Microsoft.FSharp.Compiler.AbstractIL.ILBinaryWriter+MethodDefNotFound' was thrown. [c:\temp\foop\foop.fsproj]

Build FAILED.

FSC : error FS2014: A problem occurred writing the binary 'c:\temp\foop\obj\Debug\netcoreapp2.0\foop.dll': Error in pass3 for type Program, error: Error in GetMethodRefAsMethodDefIdx for mref = ("PrintFormatLine", "Microsoft.FSharp.Core.ExtraTopLevelOperators"), error: Exception of type 'Microsoft.FSharp.Compiler.AbstractIL.ILBinaryWriter+MethodDefNotFound' was thrown. [c:\temp\foop\foop.fsproj]
    0 Warning(s)
    1 Error(s)

Time Elapsed 00:00:06.56

c:\temp\foop>

Expected:
build to succeed.

[gusty]

@cartermp Can you tell me where is this issue in the roadmap? I'm asking because you said yesterday that all .net core issues are high priority. Does it include this one?

[cartermp]

I'm not even sure what the --standalone flag does. I'm only aware of publish to produce a standalone directory with all dependencies inside, and --no-dependencies for excluding any P2P refs.

@KevinRansom what is the scenario here?

@gusty To clarify, I said that if it involves .NET Core it's of a higher priority to me. To that end, this should definitely be fixed, but I don't think I understand the scenario.

[gusty]

@KevinRansom Is it just --standalone or is it --staticlink as well?

[dsyme]

@cartermp --standalone allows a form of static linking. It statically adds a copy of FSharp.Core to the .exe. It's an occasionally-useful but-not-critical part of the F# toolchain for people who want to completely hide the fact that a tool is written in F#, or to deliver a single .exe. For example Paket is delivered as a single .exe.

In the world of .NET Core it doesn't make much sense because at the moment .NET Core really involve packaging a lot of stuff with the app. Future iterations on .NET Core may be different, but at the moment I don't see it as a necessary or supported part of the toolchain. There's no harm in getting it working, but it's just not going to be commonly used.

There are other options for static linking tool, e.g. mkbundle in the Mono toolchain (an excellent option because it bundles the Mono runtime as well, all into a single .EXE) and ILMerge.

[cartermp]

Yeah, it sounds like it's not applicable to .NET Core right now, since there is no currently supported option to produce a single .exe. I think we should relabel this as an enhancement instead of a bug.