Fantoom/aspire-cli-debugging by Fantoom · Pull Request #769 · JetBrains/aspire-plugin

Fantoom · 2026-11-03T09:25:21Z

No description provided.

jetbrains-air

Please address the blocking inline finding before merging.

Allow the Debug executor for the Aspire CLI run configuration. On Debug, `aspire run` is started with `ASPIRE_WAIT_FOR_DEBUGGER`, so the AppHost blocks in `DistributedApplication.CreateBuilder` until the .NET debugger attaches to it via the new `appHostDebugger` extension point. `DEBUG_SESSION_RUN_MODE` is set explicitly so child sessions are debugged only on Debug.

Rival Abdrakhmanov (rafaelldi) · 2026-11-05T07:45:06Z

 ### Added

 - Resource watching for the Aspire CLI run configuration
+- Debugging of the AppHost launched by the Aspire CLI run configuration


It should be under the Unreleased section

Rival Abdrakhmanov (rafaelldi) · 2026-11-05T07:47:55Z

+import kotlinx.coroutines.CoroutineScope
+import java.nio.file.Path
+
+interface AppHostDebuggerExtension {


@ApiStatus.Internal

Rival Abdrakhmanov (rafaelldi) · 2026-11-05T07:49:22Z

+            EP_NAME.extensionList.sortedBy { it.priority }.firstOrNull { it.isApplicable(appHostFilePath) }
+    }
+
+    val priority: Int


We probably don't need priority as we don't have multiple debugger for the same apphost type

Rival Abdrakhmanov (rafaelldi) · 2026-11-05T07:51:43Z

+
+    fun isApplicable(appHostFilePath: Path): Boolean
+
+    suspend fun attachToAppHost(appHostFilePath: Path, cliProcessPid: Long, project: Project, scope: CoroutineScope): Result<Unit>


Let's maybe make an ext function instead of the scope parameter: CoroutineScope.attachToAppHost(appHostFilePath: Path, cliProcessPid: Long, project: Project)

Rival Abdrakhmanov (rafaelldi) · 2026-11-05T08:12:00Z

 const val DEBUG_SESSION_SERVER_CERTIFICATE = "DEBUG_SESSION_SERVER_CERTIFICATE"
 const val DCP_INSTANCE_ID_PREFIX = "DCP_INSTANCE_ID_PREFIX"
+
+// Launch mode the AppHost puts on the launch configurations of its DCP `run_session` requests.


Maybe this is an obvious comment, so we can remove it

Rival Abdrakhmanov (rafaelldi) · 2026-11-05T08:14:13Z

 run.editor.open.browser=Open browser
 run.editor.url=URL

+configurable.Aspire=Aspire


Not sure about these configurable... strings. We already have them in the frontend part

Rival Abdrakhmanov (rafaelldi) · 2026-11-05T08:17:43Z

            checkBox(AspireCoreFrontendBundle.message("configurable.Aspire.connect.to.dcp.via.https"))
                .bindSelected(settings::connectToDcpViaHttps)
        }
+        row {


Tbh, it doesn't looks great:

Rival Abdrakhmanov (rafaelldi) · 2026-11-05T08:23:40Z

+            checkBox(AspireCoreFrontendBundle.message("configurable.Aspire.show.app.host.not.debugged.notification"))
+                .bindSelected(settings::showAppHostNotDebuggedNotification)
+        }
+        row(AspireCoreFrontendBundle.message("configurable.Aspire.app.host.attach.timeout")) {


Units (seconds here) are ussually placed after the text field (see: https://plugins.jetbrains.com/docs/intellij/data-formats.html#units)

I think that the comment is redundant here. It almost says the same as the label.

Probably, it is visually better to place text fields together and them the comboboxes.

Rival Abdrakhmanov (rafaelldi) · 2026-11-05T08:26:13Z

+import kotlin.io.path.nameWithoutExtension
+import kotlin.time.Duration.Companion.seconds
+
+private val Path.pathWithoutExeOrDllExtension: Path


Let's move it to some util or extension class/file

Rival Abdrakhmanov (rafaelldi) · 2026-11-05T08:28:38Z

+        project: Project,
+        scope: CoroutineScope
+    ): Result<Unit> {
+        // Terminated when the run's scope is cancelled.


Probably the comment is obvious

Rival Abdrakhmanov (rafaelldi) · 2026-11-05T08:30:09Z

+    }
+
+internal class DotNetAppHostDebuggerExtension : AppHostDebuggerExtension {
+    companion object {


A warning here: Companion objects in IDE extension implementations may only contain a logger and constants

Rival Abdrakhmanov (rafaelldi) · 2026-11-05T08:32:47Z

    return project.solution.runnableProjectsModel.findBySessionProject(projectPath, runnablePredicate)
 }

+suspend fun findRunnableProjectByPathSuspending(


Let's remove the non-suspend variant

Rival Abdrakhmanov (rafaelldi) · 2026-11-05T08:35:53Z

+        if (outputPaths.isNullOrEmpty()) {
+            LOG.trace { "Unable to find the project output for $appHostFilePath" }
+            return emptyList()
+        }


We already log the warning in the parent attachToAppHost method if the outputs is empty. We probably don't need to log it here

Rival Abdrakhmanov (rafaelldi) · 2026-11-05T08:40:44Z

+
+    private suspend fun isAppHostProcess(process: EelProcessInfo, outputs: List<ProjectOutput>): Boolean {
+        val executable = process.executable ?: return false
+        val outputPaths = outputs.mapNotNull { it.exePath.toNioPathOrNull()?.pathWithoutExeOrDllExtension }


Let's create this in the parent findAppHostPid method and reuse for all the processes

Rival Abdrakhmanov (rafaelldi) · 2026-11-05T08:43:11Z

+        else -> this
+    }
+
+internal class DotNetAppHostDebuggerExtension : AppHostDebuggerExtension {


I would suggest to implement this logic in a separate service and just call the service from the ext point. Services are more friendly for testing and reusing

Rival Abdrakhmanov (rafaelldi) · 2026-11-05T08:44:05Z

+    }
+
+    /**
+     * Returns the PID of the first descendant of [cliProcessPid] running the AppHost [outputs], or `null` when it


I believe this is clear too, so we don't need the comment

Rival Abdrakhmanov (rafaelldi) · 2026-11-05T08:49:35Z

+    }
+
+    private fun resolveAppHostDebugger(appHostFilePath: Path): AppHostDebuggerExtension? {
+        // Attaching to the AppHost process is local-only (the debugger discovers and attaches to a local


Attaching to the AppHost process is local-only -- is it?

Rival Abdrakhmanov (rafaelldi) · 2026-11-05T09:36:52Z

+        val project = environment.project
+
+        // Canceled on process termination, so a stop mid-attach cancels the polling cleanly.
+        val attachScope = AspireService.getInstance(project).scope.childScope("Aspire AppHost debugger attach")


I think that we shuould mark attachDebuggerToAppHost as suspend and reuse its scope instead of creating our own and managing it with ProcessListener. I believe that the parent suspend method will be cancelled if the target run configuration application couldn't start

Fantoom requested a review from Rival Abdrakhmanov (rafaelldi) November 3, 2026 09:25

Fantoom self-assigned this Nov 3, 2026

jetbrains-air Bot requested changes Nov 3, 2026

View reviewed changes

Comment thread core/src/main/kotlin/com/jetbrains/aspire/run/cli/AspireCliRunProfileState.kt Resolved

Fantoom force-pushed the Fantoom/aspire-cli-debugging branch 3 times, most recently from 9381467 to 593a2f0 Compare November 3, 2026 11:28

Fantoom force-pushed the Fantoom/aspire-cli-debugging branch from 593a2f0 to 610f9c0 Compare November 4, 2026 09:29

Rival Abdrakhmanov (rafaelldi) reviewed Nov 5, 2026

View reviewed changes

Rival Abdrakhmanov (rafaelldi) requested changes Nov 5, 2026

View reviewed changes


		fun isApplicable(appHostFilePath: Path): Boolean

		suspend fun attachToAppHost(appHostFilePath: Path, cliProcessPid: Long, project: Project, scope: CoroutineScope): Result<Unit>

Conversation

Fantoom commented Nov 3, 2026

Uh oh!

jetbrains-air Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants