How diagnose "IDE returned a response indicating failure: Error = run session could not be started"?

[Paulo Morgado (paulomorgado)]

Every now and then we get this in some projects when launching from Visual Studio 2026:

 [sys] run session could not be started: IDE returned a response indicating failure: Error = run session could not be started: IDE returned unexpected status code for Executable run request: 500 Internal Server Error
 [sys] An attempt to start the Executable failed: Error = run session could not be started: IDE returned unexpected status code for Executable run request: 500 Internal Server Error
 [sys] The Executable failed to start: Error = all available Executable runners have been tried and failed

But it runs fine with aspire run and from VSCode.

How can we diagnose this?

[Morvay (morvayo)]

that message is the ide runner rejecting the launch request so collect diagnostics from the failing visual studio launch rather than the successful cli run

in the active apphost launch profile add DCP_DIAGNOSTICS_LOG_LEVEL=debug and DCP_DIAGNOSTICS_LOG_FOLDER pointing to a writable folder then reproduce from visual studio

look for the executable run request and its 500 response body alongside the visual studio aspire output

include the vs build and aspire version with those sanitized excerpts in the report

diagnostic options and debug launch example

[Paulo Morgado (paulomorgado)]

Looks like this is an Heisenbug. 😄

With that logging, the issue doesn't happen.

[Morvay (morvayo)]

that is useful evidence but it does not establish the cause or mean it is fixed

try removing only DCP_DIAGNOSTICS_LOG_LEVEL=debug while keeping the log folder set and repeat the same visual studio launch

that separates the extra verbosity from changing the log destination

if the failure returns capture the visual studio aspire output and use visual studio report a problem immediately after the failed launch with the vs and aspire versions

include that enabling debug logging suppresses the failure since that is an important reproduction detail

[Paulo Morgado (paulomorgado)]

Morvay (@morvayo), is the value for DCP_DIAGNOSTICS_LOG_FOLDER a relative or absolute path?

[Hajdú Patrik (hajdu-patrik)]

Use an absolute path.

The AppHost doesn't normalize the value; DCP gets it verbatim:

• DcpHost.cs copies the AppHost's environment into the DCP process, so DCP_DIAGNOSTICS_LOG_FOLDER from your launch profile reaches DCP unchanged. DcpPublisher:DiagnosticsLogFolder in AppHost config overrides it, also verbatim (DcpOptions.cs).
• DCP is started with WorkingDirectory = Directory.GetCurrentDirectory() of the AppHost.

A relative path therefore depends on the AppHost's working directory, which can differ between VS, dotnet run and aspire run. That's not what you want while chasing a VS-only failure.

"environmentVariables": {
  "DCP_DIAGNOSTICS_LOG_FOLDER": "C:\\temp\\dcp-logs"
}

For the Heisenbug, keep the folder but drop DCP_DIAGNOSTICS_LOG_LEVEL=debug. Debug logging changes timing, which is consistent with a race between DCP and the VS run-session endpoint that returns the 500.

[Paulo Morgado (paulomorgado)]

I was able to figure out what was going on. The project was not even being compiled. Maybe related to the migration from AddProject to AddDotnetProject.

[Hajdú Patrik (hajdu-patrik)]

That matches how AddDotnetProject works: Aspire builds the services itself, but only when the IDE supports project-with-external-build.v1. aspire run and VS Code take that path. VS falls back to the old one, where it has to build the project itself. Without the ProjectReference nothing builds it, so the run request fails with a 500. It only happens "now and then" because a leftover build from aspire run or VS Code hides the problem until the next clean or source change. That also explains the logging "Heisenbug", so it isn't a race after all.

Workaround: keep a build-order-only reference in the AppHost:

<ProjectReference Include="..\MyService\MyService.csproj"
                  IsAspireProjectResource="false"
                  ReferenceOutputAssembly="false" />

Worth reporting to VS as well.