Allow running `dotnet app.exe` instead of `dotnet app.dll`

When I target net5.0 for an exe app, both app.dll and app.exe are published to output.

Running dotnet app.dll works fine, but running dotnet app.exe doesn’t work:

C:\MetadataTools>dotnet C:\MetadataTools\src\BinaryCompatChecker\bin\Debug\net5.0\BinaryCompatChecker.exe
Error:
  An assembly specified in the application dependencies manifest (BinaryCompatChecker.deps.json) has already been found but with a different file extension:
    package: 'BinaryCompatChecker', version: '1.0.0'
    path: 'BinaryCompatChecker.dll'
    previously found assembly: 'C:\MetadataTools\src\BinaryCompatChecker\bin\Debug\net5.0\BinaryCompatChecker.exe'

This is not a great experience: we know what the user wants, let’s just do the right thing.

The scenario is: an app is shipping both .dll and .exe. Some script runs the .exe. One should be able to prepend dotnet to run the .exe using .NET (by default it is run using Mono on Mac). Now I need to not only prepend dotnet, but also switch from .exe to .dll.

This is all very confusing for me, imagine how confusing it is for other users.

[agocke]

I think the error message should be “app.exe is a native executable, not a .NET DLL. Native exes should not be executed with dotnet, but run directly.”

I disagree with the philosophy that we should “just run the exe” because it points to a potential confusion on the part of the user that doesn’t get corrected, it potentially lets through a bug in the case that the exe is not a managed app at all, and it biases a non-preferred scenario (using dotnet app.dll) over the preferred scenario (use the apphost).

[agocke]

Nope, it’s a native binary. The default deployment experience for the SDK (on any platform) is OS-specific. Portable apps do not use the apphost.