runtime: dotnet is not able to run programs compiled with csc

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.

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Comments: 15 (12 by maintainers)

Most upvoted comments

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 https://github.com/dotnet/designs/pull/296 for this experience.

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 https://github.com/dotnet/designs/pull/296 proposal that I have linked above is trying to address.

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.

Closing as not planned. https://github.com/dotnet/designs/pull/296 is the closest proposal for this experience.

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.