Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for --standalone on .NET Core #3924

Closed
KevinRansom opened this issue Nov 11, 2017 · 7 comments · Fixed by #7462
Closed

Support for --standalone on .NET Core #3924

KevinRansom opened this issue Nov 11, 2017 · 7 comments · Fixed by #7462

Comments

@KevinRansom
Copy link
Member

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.

@dsyme dsyme added Bug Impact-Medium (Internal MS Team use only) Describes an issue with moderate impact on existing code. labels Nov 17, 2017
gusty added a commit to fsprojects/FSharpPlus that referenced this issue Nov 30, 2017
gusty added a commit to fsprojects/FSharpPlus that referenced this issue Nov 30, 2017
@gusty
Copy link
Contributor

gusty commented Feb 23, 2018

@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
Copy link
Contributor

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
Copy link
Contributor

gusty commented Feb 23, 2018

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

@dsyme
Copy link
Contributor

dsyme commented Feb 23, 2018

@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
Copy link
Contributor

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.

@dsyme dsyme added Feature Improvement and removed Impact-Medium (Internal MS Team use only) Describes an issue with moderate impact on existing code. Bug labels Feb 24, 2018
@cartermp cartermp changed the title --standalone does not work on coreclr Support for --standalone on .NET Core Feb 26, 2018
@cartermp cartermp added this to the Unknown milestone Aug 25, 2018
@drvink
Copy link
Contributor

drvink commented Jan 12, 2019

I just hit this bug myself--while it's definitely not something used by many folks, it's fairly useful for the reasons Don mentioned.

Another benefit worth mentioning is that with single-.exe publishing, you're able to run monolinker on the .exe, which often dramatically reduces their size due to the ability to prune dead code (just like when linking with static libraries for traditional PE/ELF/etc. toolchains). monolinker will also work with dotnet publish --self-contained, but fixing this issue would allow for shipping tiny single .exes again.

@NatElkins
Copy link
Contributor

Here's another tool that might be useful to others: https://github.com/dgiagio/warp#quickstart-with-net-core

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants