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.

elinor-fung on Aug 11, 2023

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.

jkotas on Aug 7, 2023

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.

jkotas on Aug 7, 2023

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

agocke on Aug 17, 2023

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.

am11 on Aug 6, 2023