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)
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.
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
. Generatingruntimeconfig.json
is one of the many things thatdotnet build
takes care of in addition to invoking C# compiler. I do not expect us to duplicate thedotnet 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.
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.