Launch always goes through the dotnet muxer, so a self-contained app cannot be launched

[nevse]

PerformLaunch hardcodes the host:

var processStartInfo = new ProcessStartInfo
{
    FileName = "dotnet",
    ArgumentList = { launchInfo.Program },

For a framework-dependent app that is right. For a self-contained one it is not: the published artefact is a native apphost, and the muxer cannot run it.

$ dotnet publish -r osx-arm64 --self-contained true -o out
$ ./out/MyApp                 # works
PID=17440
tick 1
$ dotnet ./out/MyApp          # what PerformLaunch does
Could not execute because the specified command or file was not found.

Passing the .dll instead is not a fix, only a quieter failure: dotnet ./out/MyApp.dll starts, but on the shared runtime rather than the one published alongside the app — so it fails on a machine without a matching runtime installed, and a single-file publish has no .dll to point at at all.

A launch configuration naming an executable rather than a .dll looks like the signal to use: run it directly, with launchInfo.Program as FileName and no dotnet in front. DOTNET_DefaultDiagnosticPortSuspend=1 is set through the environment, so it carries over either way.

I have not driven this through an actual LaunchRequest — the report is from reading PerformLaunch plus the shell behaviour above. Attach is unaffected, which is why my own server never hit it.

[MattParkerDev]

I will fix this when I find time - I will be honest - Launch was contributed by the community and was not a super high priority initially - SharpIDE uses Attach exclusively, because it gives much greater control over the started process.

[MattParkerDev]

Fix released in 0.1.11 :)