dotnet is not able to run programs compiled with csc

[Zeioth]

Description

running

csc Program.cs -out:Program.exe
dotnet program.exe

returns

A fatal error was encountered. The library 'libhostpolicy.so' required to execute the application was not found in './bin/'.
Failed to run as a self-contained app.
  - The application was run as a self-contained app because './Program.
runtimeconfig.json' was not found.
  - If this should be a framework-dependent app, add the './Program.run
timeconfig.json' file and specify the appropriate framework.

But running

mono Program.exe

I can run my program correctly, no matter if it's been generated, by csc, dotnet, or any other C# compiler.

Reproduction Steps

Try to run a C# program not generated by dotnet using the dotnet interpreter like:

dotnet ./Program.exe

Expected behavior

It should be able to at least run the program, no questions asked.

Actual behavior

Error asking for runtimeconfig.json

Regression?

Using the mono interpreter.

Known Workarounds

No response

Configuration

No response

Other information

Aditionally, dotnet is only able to run the executable if it has .exe or .dll extension, which again is not an issue found in the mono interpreter.

[ghost]

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

running

csc Program.cs -out:Program.exe
dotnet program.exe

returns

A fatal error was encountered. The library 'libhostpolicy.so' required to execute the application was not found in './bin/'.
Failed to run as a self-contained app.
  - The application was run as a self-contained app because './Program.
runtimeconfig.json' was not found.
  - If this should be a framework-dependent app, add the './Program.run
timeconfig.json' file and specify the appropriate framework.

But running

mono Program.exe

I can run my program correctly, no matter if it's been generated, by csc, dotnet, or any other C# compiler.

Reproduction Steps

Try to run a C# program not generated by dotnet using dotnet like:

dotnet ./Program.exe

Expected behavior

It should be able to at least run the program, no questions asked.

Actual behavior

Error asking for runtimeconfig.json

Regression?

Using the mono interpreter.

Known Workarounds

No response

Configuration

No response

Other information

Aditionally, dotnet is only able to run the executable if it has .exe or .dll extension, which again is not an issue found in the mono interpreter.

Author:	Zeioth
Assignees:	-
Labels:	area-Host, untriaged
Milestone:	-

[am11]

dotnet requires runtimeconfig.json. There is a script at https://stackoverflow.com/a/56133028/863980 for environment profile, which discovers the versions and creates csc and csc_run aliases.

$ csc -version 
4.6.0-3.23259.8 (c3cc1d0c)

# compile code with physical file
$ csc Program.cs -nologo -out:Program.exe

# csc now also supports reading code from stdin
$ csc - -nologo -out:Program.exe <<EOF
using System;
Console.WriteLine("Hello World!");
EOF

$ csc_run Program.exe
Hello World!

[Zeioth]

Thank you @am11, that script is great, and it should certainly be the way dotnet behaves by default.

I'm the author of compiler.nvim, which allows building C# programs with csc (for projects without a csproj file), or dotnet (for projects with a .csproj file).

And when compiling with csc, I'm currently forced to include the mono JIT compiler as dependency, so the user is able able to run the program (which is currently abandonware).

This shouldn't be necessary. Dotnet should at least try to find the necessary .NET version to run, as the mono JIT has been doing successfully for many years.

[am11]

it should certainly be the way dotnet behaves by default.

That would be nice if dotnet fallback to the default configurations to enable this scenario. @elinor-fung, what do you think about changing the default behavior, or supporting the existing SDK option --ucr, --use-current-runtime directly in the host to enable this scenario?

@Zeioth, in the meanwhile, you may want to generate the runtimeOptions in json like csc-console-apps.runtimeconfig.json from the linked script.

[jkotas]

Dotnet should at least try to find the necessary .NET version to run

The .exe alone does not have sufficient information to reliably identify necessary version to run. We do not want to introduce an experience where the host guesses a version and then the program fails sometime later with cryptic error because of it requires a newer version.

dotnet/designs#296 is related to this.

[Zeioth]

@jkotas In that case adding an option to csc to generate runtimeconfig.json along with the exe, the same way dotnet does, could be a desirable alternative.

The most important case of use is being able to run the executable generated by csc as dotnet Program.exe without manual intervention.

[jkotas]

Building of binaries for modern .NET is meant to be done by calling dotnet build. Generating runtimeconfig.json is one of the many things that dotnet build takes care of in addition to invoking C# compiler. I do not expect us to duplicate the dotnet build functionality as csc.exe command like options.

[am11]

We do not want to introduce an experience where the host guesses

I was proposing to reuse dotnet publish's --use-current-runtime option for dotnet exec app.exe and dotnet app.exe. There are no guesses with that approach.

Building of binaries for modern .NET is meant to be done by calling dotnet build.

Well, there is clearly a demand to do things faster for IDEs and other continuous build pipeline scenarios where dotnet build, even with its --no-xxx flags simply does not scale. Which is why people are resorting to manually invoking the tools which dotnet is trying to wrap under the covers. e.g. try using C# in https://godbolt.org/, it is by far the slowest compilation compared to any other languages they support, just because it uses dotnet build.

[jkotas]

I was proposing to reuse dotnet publish's --use-current-runtime option for dotnet exec app.exe and dotnet app.exe. There are no guesses with that approach.

There is nothing that guarantees that the current runtime is sufficient for the app.exe. You are right that the runtime does not need to guess in this case, but the experience when the current runtime is not sufficient to run the app.exe is still poor.

there is clearly a demand to do things faster for IDEs and other continuous build pipeline scenarios where dotnet build

If people believe that they can do better and want to ship what msbuild does for them, they need to duplicate it on their own.

try using C# in https://godbolt.org/

This does not look like a problem with msbuild. It looks like a problem with crossgen2 and with how godbolt invokes it.

[Zeioth]

Building of binaries for modern .NET is meant to be done by calling dotnet build. Generating runtimeconfig.json is one of the many things that dotnet build takes care of in addition to invoking C# compiler. I do not expect us to duplicate the dotnet build functionality as csc.exe command like options.

By forcing the user to do dotnet build, we are obligating him to manually create a project file just to be able to compile, when there is no real reason for it.

You write a main.cs file, you compile it, and you should be able to run it.

If we cannot achieve this, it's gonna impact the language adoption.

[jkotas]

By forcing the user to do dotnet build, we are obligating him to manually create a project file just to be able to compile, when there is no real reason for it.

This is what dotnet/designs#296 proposal that I have linked above is trying to address.

[AaronRobinsonMSFT]

/cc @jaredpar @chsienki

[elinor-fung]

I was proposing to reuse dotnet publish's --use-current-runtime option for dotnet exec app.exe and dotnet app.exe. There are no guesses with that approach.

There is nothing that guarantees that the current runtime is sufficient for the app.exe. You are right that the runtime does not need to guess in this case, but the experience when the current runtime is not sufficient to run the app.exe is still poor.

I'd rather not add anything on the host side that just tries to use the latest runtime installed. It'd have no idea if that version is what is needed, there are other dependencies, it uses other shared frameworks, etc.

I think we should stick with dotnet/designs#296 for this experience.

[am11]

I'd rather not add anything on the host side that just tries to use the latest runtime installed. I

Fair enough. I guess folks into unix-y tools would appreciate this kind of experience, but if it too complicated to implement (with reasonable limitations), then it's probably not worth it.

It'd have no idea if that version is what is needed, there are other dependencies, it uses other shared frameworks, etc.

I think in that case, application will fail to run and user will get similar experience when there is an unavailable or incompatible version specified in runtimeconfig.json. The error messages host issues are discoverable / googleable and well understood by masses at this point.

Once upon a time, we implemented dotnet/roslyn@f4f3aa7, and I very much wanted to compile and run code from stdin (like native and many platform compilers support), but after the Roslyn episode, I couldn't find a way to hook that into SDK and msbuild (for one, System.Commandline was missing stdin support and then there was MSBuild's requirement of physical file). Ever since, I have that csc alias in my portable .profile file. Working like a charm for a handful of .NET releases (at least for simple stuff). 🙂

[agocke]

Closing as not planned. dotnet/designs#296 is the closest proposal for this experience.