search

dotnet / sdk

Core functionality needed to create .NET Core projects, that is shared between Visual Studio and CLI
https://dot.net/core
MIT License
2.75k stars 1.07k forks source link

Allow running simple .exe files without .runtimeconfig.json #22384

Open KirillOsenkov opened 3 years ago

KirillOsenkov commented 3 years ago

It is currently impossible to execute simple console applications (.exe) compiled against net472 using dotnet myapp.exe.

The output we get is something along these lines:

Cannot use file stream for [/Users/builder/azdo/_work/1/s/setup/MacSetup/build/packages/binarycompatchecker/1.0.20/tools/BinaryCompatChecker.deps.json]: No such file or directory
A fatal error was encountered. The library 'libhostpolicy.dylib' required to execute the application was not found in '/Users/builder/azdo/_work/1/s/setup/MacSetup/build/packages/binarycompatchecker/1.0.20/tools/'.
Failed to run as a self-contained app.
The application was run as a self-contained app because '/Users/builder/azdo/_work/1/s/setup/MacSetup/build/packages/binarycompatchecker/1.0.20/tools/BinaryCompatChecker.runtimeconfig.json' was not found.
If this should be a framework-dependent app, add the '/Users/builder/azdo/_work/1/s/setup/MacSetup/build/packages/binarycompatchecker/1.0.20/tools/BinaryCompatChecker.runtimeconfig.json' file and specify the appropriate framework.

This is not user friendly at all. The expectation is that for most programs compiled against net472 they should just run by prepending dotnet. Forcing to add a .runtimeconfig.json sounds like a sound requirement in theory, but in practice this adds friction to the 90% case (simplest scenario).

AArnott commented 3 years ago

The expectation is that for most programs compiled against net472 they should just run by prepending dotnet

What runtime would it run on? .NET Core, presumably. But which version of the runtime?

Why do you expect an exe built for a different runtime to run on Core? If you know it's .NET Framework, why not just run the .exe? And if you don't know which runtime, do you expect dotnet some.exe to work if .exe is a native binary too?

darthwalsh commented 3 years ago

What runtime would it run on? .NET Core, presumably. But which version of the runtime?

Config files shouldn't be mandatory. I'd like a CLI flag to configure the runtime. And assuming the latest installed runtime feels like a user-friendly assumption.

KirillOsenkov commented 3 years ago

Just pick the latest available Core runtime and hope for the best. There are situations where you have an existing tool compiled for net472 that you want to run on Mac. You can run on Mono without problems, but you can't run on dotnet for an artificial reason/limitation.

I don't think dotnet some.exe should work for native binaries, but that's not the scenario I care about. In 90% cases you can run .NET Framework apps just fine if you manually add a .runtimeconfig.json file. I think it's silly to have this artificial impediment.

dotMorten commented 3 years ago

In 90% cases you can run .NET Framework apps just fine

And the other cases? This seems like a slippery slope and might add a bunch of confusion rather that updating tools to netcore. Running NETFX apps on MacOS feels like a hack, so seems fair to me you have to do a bit of manual hacking.

abatishchev commented 3 years ago

And the other cases?

Doesn't matter. If in 90% it'll work - it's already a huge win for the customers.

Following this logic, nothing needs any improvement ever if there will be always a corner case which won't be fixed/improved.

Catering to ~90% of customers sounds to me like a good reason for a change.

dotMorten commented 3 years ago

Not sure where that 90% number comes from (most NETFX apps I see are using Windows APIs). I don't buy your "following that logic" extrapolation argument either. I think there's a story and expectations to consider as well. It might be the app runs fine until one day a different code path is taken and it suddenly doesn't, and it'll be very hard to troubleshoot. Or something as simple as file separator is used different. This just feels like setting people up for problems by making this a "supported" scenario.