Separate regular arguments from launch tool ("entrypoint") arguments

[Karol Zadora-Przylecki (karolz-ms)]

Description

WithDebugSupport's argsCallback subtracted the tool entrypoint (go run <pkg>, python -m <mod>) via an ordinary WithArgs callback — so it only worked if registered after the callback that added the prefix, it left the app model IDE-only, and it permanently forfeited Process fallback.

This fixes the issue by separating the "prefix" (a.k.a. "entrypoint") arguments from ordinary arguments.

Fixes #18929

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No
• Did you add public API?
  • Yes
    • If yes, did you have an API Review for it?
      • Yes
      • No
    • Did you add <remarks /> and <code /> elements on your triple slash comments?
      • Yes
      • No
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
    • If yes, have you done a threat model and had a security review?
      • Yes
      • No
  • No

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 18999

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 18999"

[Copilot]

Pull request overview

Separates tool-entrypoint arguments from program arguments, removing debug registration-order sensitivity while preserving accurate app-model command lines.

Changes:

• Adds entrypoint argument annotations and evaluation.
• Updates DCP launch/fallback composition.
• Migrates Go, Python, and .NET integrations with regression tests.

Reviewed changes

Copilot reviewed 15 out of 15 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/Aspire.Hosting/ResourceBuilderExtensions.cs	Adds entrypoint argument APIs.
src/Aspire.Hosting/ApplicationModel/EntrypointArgsCallbackAnnotation.cs	Models entrypoint arguments.
src/Aspire.Hosting/ApplicationModel/ArgumentsExecutionConfigurationGatherer.cs	Prepends entrypoint arguments.
src/Aspire.Hosting/SupportsDebuggingAnnotation.cs	Removes rewrite tracking.
src/Aspire.Hosting/Utils/ExtensionUtils.cs	Matches entrypoints to launch types.
src/Aspire.Hosting/Dcp/ExecutableCreator.cs	Composes IDE/process arguments and fallback.
src/Aspire.Hosting/Dcp/DcpExecutor.cs	Invalidates entrypoint callback caches.
src/Aspire.Hosting.Go/GoHostingExtensions.cs	Separates Go tool and program arguments.
src/Aspire.Hosting.Python/PythonAppResourceBuilderExtensions.cs	Separates Python entrypoints.
src/Aspire.Hosting.Dotnet/DotnetProjectHostingExtensions.cs	Adapts .NET launch scaffolding.
tests/Aspire.Hosting.Tests/ExecutableResourceBuilderExtensionTests.cs	Tests entrypoint semantics.
tests/Aspire.Hosting.Tests/Dcp/DcpExecutorTests.cs	Tests DCP composition and fallback.
tests/Aspire.Hosting.Go.Tests/AddGoAppTests.cs	Tests Go argument ordering.
tests/Aspire.Hosting.Python.Tests/AddPythonAppTests.cs	Tests Python entrypoints.
tests/Aspire.Hosting.Dotnet.Tests/DotnetProjectResourceTests.cs	Tests custom .NET entrypoints.

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[Alex Crome (afscrome)]

Does this overlap with #18904 - e.g. should DotnetToolResource use this for the dotnet tool exec portion of the args.

How does this overlap with how the dashboard renders args - for dotnet tool resoruce I had to jump through some hoops to hide those arguments, which resulted in some special casing. Would the dashboard still show these exec arguments, or would they be hidden on the main view, and only viewable on the detailed resource properties pane.

aspire/src/Aspire.Hosting/Dcp/ExecutableCreator.cs

Lines 670 to 678 in 30190f9

	else if (er.ModelResource is DotnetToolResource)
	{
	var argSeparator = appHostArgList.Select((a, i) => (index: i, value: a.Value))
	.FirstOrDefault(x => x.value == DotnetToolResourceExtensions.ArgumentSeparator);
	var args = appHostArgList.Select((a, i) => (arg: a, display: i > argSeparator.index));
	launchArgs.AddRange(args.Select(x => CreateLaunchArgument(x.arg.Value, x.arg.IsSensitive, executable: true, x.display)));
	return launchArgs;
	}

[Copilot]

Pull request overview

Copilot reviewed 16 out of 16 changed files in this pull request and generated no new comments.

Suppressed comments (2)

src/Aspire.Hosting/Dcp/ExecutableCreator.cs:280

• This still disables the DCP Process fallback whenever a non-empty entrypoint is withheld. That leaves the affected Go/Python-style resources with FallbackExecutionTypes = null, contradicting the PR description's claim that separating these arguments fixes the permanently forfeited Process fallback. Please retain a separate process-form argument list (or otherwise teach DCP to compose the full command on fallback); otherwise an IDE launch rejection still cannot fall back to Process.

        if (spec.ExecutionType != ExecutionType.IDE || omittedEntrypointArgumentCount > 0)
        {
            return false;

src/Aspire.Hosting/ApplicationModel/ArgumentsExecutionConfigurationGatherer.cs:57

• This suppresses entrypoint arguments for every ContainerResource, even though the new public WithEntrypointArgs<T> API accepts any IResourceWithArgs—including ordinary containers—and documents that the prefix is present outside the owning IDE launch. A direct call on AddContainer(...) therefore succeeds but silently contributes no arguments. Please scope this workaround specifically to containers synthesized by PublishAsDockerFile (for example via an internal marker), or reject container builders at the API boundary instead of dropping their configuration.

        if (resource is ContainerResource)
        {
            return;

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[Copilot]

Pull request overview

Copilot reviewed 17 out of 17 changed files in this pull request and generated no new comments.

Suppressed comments (5)

src/Aspire.Hosting/ApplicationModel/ArgumentsExecutionConfigurationGatherer.cs:57

• WithEntrypointArgs is available on ContainerResource through IResourceWithArgs, but this unconditional return discards explicitly declared entrypoint arguments for every container in both run and publish modes. It also contradicts the new API contract that these arguments participate in process/publish command lines. Skip only annotations inherited by PublishAsDockerFile (or remove that inherited annotation during conversion), rather than disabling the feature for all containers.

        if (resource is ContainerResource)
        {
            return;

src/Aspire.Hosting/ResourceBuilderExtensions.cs:4784

• This constraint exposes the API on ProjectResource and DotnetProjectResource, but their non-debug process paths still emit Aspire's default dotnet run --project/--file scaffold. Because SupportsDebugging is false outside a debug session, a matching custom entrypoint is composed together with that scaffold instead of replacing it, so it is not the leading tool invocation promised here and can produce a broken dotnet command. Suppress the project scaffold whenever the matching entrypoint declaration owns it in process mode as well, and cover both project resource shapes without a debug session.

    public static IResourceBuilder<T> WithEntrypointArgs<T>(this IResourceBuilder<T> builder, string launchConfigurationType, Action<CommandLineArgsCallbackContext> callback)
        where T : IResourceWithArgs

src/Aspire.Hosting/ApplicationModel/EntrypointArgsCallbackAnnotation.cs:32

• Resource dependency discovery still evaluates only CommandLineArgsCallbackAnnotation (ResourceExtensions.cs:1601-1625). Values such as EndpointReference or ReferenceExpression added through this new callback therefore disappear from GetResourceDependenciesAsync; for containers, that can prevent required host-tunnel setup. Include the active entrypoint callback in raw argument dependency discovery and add coverage for an IValueWithReferences entrypoint argument.

internal sealed class EntrypointArgsCallbackAnnotation : IResourceAnnotation, IArgCallbackAnnotation

src/Aspire.Hosting/ApplicationModel/ArgumentsExecutionConfigurationGatherer.cs:80

• The shipped ProcessArgumentValuesAsync path still calls GatherArgumentValuesAsync, which enumerates only CommandLineArgsCallbackAnnotation (ResourceExtensions.cs:267-288). After Go and Python move their prefixes to this new gatherer path, that public helper silently reports only program arguments instead of the resource's full command line. Route the legacy helper through ExecutionConfigurationBuilder or teach it to prepend the active entrypoint callback result.

        var entrypointArgs = await entrypointAnnotation.AsCallbackAnnotation().EvaluateOnceAsync(entrypointContext).ConfigureAwait(false);
        if (entrypointArgs.Count == 0)
        {
            return;
        }

        context.Arguments.InsertRange(0, entrypointArgs);
        context.AddAdditionalData(new EntrypointArgumentsData(entrypointArgs.Count));

src/Aspire.Hosting/ResourceBuilderExtensions.cs:4780

• This new public fluent API has no <example>/<code> section, despite the repository XML documentation standard requiring examples for extension methods and the PR checklist stating that one was added. Add a concrete example showing the tool prefix declared separately from ordinary WithArgs values.

    /// <para>
    /// Calling this method more than once is allowed; the most recent declaration wins.
    /// </para>
    /// </remarks>

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[Copilot]

Pull request overview

Copilot reviewed 18 out of 18 changed files in this pull request and generated no new comments.

Suppressed comments (3)

src/Aspire.Hosting/ApplicationModel/ArgumentsExecutionConfigurationGatherer.cs:57

• ContainerResource also implements IResourceWithArgs, so this blanket return silently drops entrypoint arguments explicitly declared on ordinary containers and from their published manifests. That contradicts WithEntrypointArgs' documented process/publish behavior. Suppress or remove the mirrored annotation specifically during PublishAsDockerFile conversion instead of disabling the API for every container.

        if (resource is ContainerResource)
        {
            return;

src/Aspire.Hosting/Dcp/ExecutableCreator.cs:306

• This unconditionally treats a ProjectResource as fallback-capable when the owned entrypoint resolves empty. For a custom debug type, preparation has already omitted the normal dotnet run --project scaffold, so both the advertised Process fallback and the launch-configuration failure path can execute bare dotnet <app-args>. Treat an owned empty entrypoint as an incomplete process command for ProjectResource too.

        if (modelResource is ProjectResource)
        {
            return true;
        }

src/Aspire.Hosting.Python/PythonAppResourceBuilderExtensions.cs:1068

• WithEntrypoint is a shipped API whose previous contract explicitly reset all command-line arguments. Replacing that clear callback with a separate prefix callback now retains arguments registered before this call, so switching a script/module can pass stale arguments to the new entrypoint. Preserve the reset for ordinary arguments, or handle this as an intentional breaking API change with migration guidance.

        builder.WithEntrypointArgs("python", static context =>

[Karol Zadora-Przylecki (karolz-ms)]

Alex Crome (@afscrome) I saw your comment, still thinking/working on how to reconcile this with #18904

[Copilot]

Pull request overview

Copilot reviewed 18 out of 18 changed files in this pull request and generated no new comments.

Suppressed comments (5)

src/Aspire.Hosting/ResourceBuilderExtensions.cs:4794

• This is a new, non-trivial fluent API, but its public XML documentation has no usage example or <code> block. Add a minimal example showing how the prefix and ownedByLaunchConfigurationType are declared so integration authors can use the ownership contract correctly.

    /// </remarks>

src/Aspire.Hosting/Dcp/ExecutableCreator.cs:242

• This broad catch also handles cancellation from the launch-configuration producer and converts it into Process fallback. Cancellation should terminate resource creation rather than changing execution mode; exclude cancellation requested through cancellationToken from the fallback catch.

        catch (Exception ex)

src/Aspire.Hosting/ResourceBuilderExtensions.cs:4769

• The new public API throws for null builder/callback and an empty ownedByLaunchConfigurationType, but its XML documentation omits those exceptions. Document both so IntelliSense describes the validation contract.

This issue also appears on line 4794 of the same file.

    /// <returns>A reference to the <see cref="IResourceBuilder{T}"/>.</returns>

src/Aspire.Hosting/ApplicationModel/DebugSupportExtensions.cs:82

• This public helper validates both parameters with ThrowIfNull, but the XML documentation does not describe the resulting exception. Add the missing exception contract for IntelliSense consumers.

    /// <returns><see langword="true"/> when the launch configuration supplies the tool invocation; otherwise, <see langword="false"/>.</returns>

src/Aspire.Hosting/Dcp/ExecutableCreator.cs:784

• DotnetToolResource returns from the special branch above before this per-prefix logic runs. Since WithLaunchToolArgs accepts every IResourceWithArgs, a dotnet tool with matching debug support will still pass its owned prefix to the IDE, and showInCommandLine is ignored. Apply the executable/display decisions in the dotnet-tool branch as well and add coverage for that resource type.

        launchArgs.AddRange(appHostArgList.Select((a, i) =>

[Karol Zadora-Przylecki (karolz-ms)]

Alex Crome (@afscrome) I have merged a change that should address your concerns. AI-supplied details follow, but hopefully they make sense.

---

Good questions — yes, it overlaps, and deliberately so. I've reshaped this PR in response so the two fit together.

The way I'd frame it: #18904 is the API-shape question (which With*Args method targets which segment), this PR is the mechanism (how a leading tool segment is represented, ordered, and selectively withheld). Option 2 needs a mechanism like this underneath — without one, an integration has no way to guarantee its tool args land before user WithArgs args, so it has to resort to registration-order tricks. Which is exactly what DotnetToolResource does today ("ensuring it registers the first .WithArgs() annotation to get the tool argument in before any arguments").

Worth noting: Go already lands on option 2 after this PR. go run <pkg> moves into the leading segment, so a plain .WithArgs() on a Go app now hits app-arg position and WithAppArgs reduces to a legacy alias.

Should DotnetToolResource use this?

Yes, eventually — but not in this PR. Three things blocked it. I've fixed the two that were artifacts of my design rather than real problems, and the API is now:

WithLaunchToolArgs(
    Action<CommandLineArgsCallbackContext> callback,
    string? ownedByLaunchConfigurationType = null,
    bool showInCommandLine = true)

(It was WithEntrypointArgs(launchConfigurationType, callback) when you looked. Renamed because "entrypoint" already means the module/script in Python's WithEntrypoint and the image ENTRYPOINT on containers — roughly the opposite of what it meant here.)

Fixed — the launch configuration type is now optional. It used to be mandatory, and dotnet tool exec has no launch configuration, so it would have needed a sentinel value. null now means "this prefix is not a debugging concern; always pass it to the program", which is the DotnetTool shape.

Fixed — display is now declared rather than implicit. showInCommandLine: false reproduces your current hiding behavior exactly, with no dashboard change.

Still open (→ #18904) — last-wins vs. additive, and the -- separator. WithLaunchToolArgs is last-wins: it's the integration declaring the tool invocation, not a place callers append flags. A user-facing WithToolArgs("--prerelease") needs to accumulate, so that's a layer on top rather than the same method. And DotnetTool's prefix ends with --, so user flags have to be inserted before it — a prepend-one-blob model can't express that. It needs a framework-emitted segment separator, appended only when the app segment is non-empty. That would also fix the current behavior of emitting a trailing -- when there are zero app args.

So the migration is a follow-up, but the primitive can absorb it without a model change. I added two tests covering the DotnetTool shape (ownedByLaunchConfigurationType: null + showInCommandLine: false) so that stays true.

Dashboard rendering

There are three surfaces, and they're driven by two independent flags plus one derived value:

• Executable → DCP Spec.Args — what actually runs
• Display → resource-app-args → KnownProperties.Resource.AppArgs → the Source column in the resources grid
• Status.EffectiveArgs → KnownProperties.Executable.Args → the details pane, always

	runs (Spec.Args)	Source column	details pane
DotnetTool prefix, today	yes	hidden	visible
launch tool args, IDE-owned	no	visible	absent
launch tool args, process execution	yes	visible	visible

So to answer directly: these args stay on the main view and are not pushed to the properties pane only. The difference from DotnetTool is defensible rather than accidental — when the IDE owns the prefix it isn't in Spec.Args, so it's absent from EffectiveArgs too. Hiding it from the Source column as well would erase run ./cmd/api from the dashboard entirely and the user would see a bare go plus app args. Your hiding is lossless because the dotnet tool exec prefix does run — it's still there in the details pane.

After this change that's a parameter on the declaration instead of something you infer from two call sites in ExecutableCreator, so DotnetTool can migrate and keep its current rendering by passing showInCommandLine: false.

One thing you may want to know about

The -- scan has a latent bug:

var argSeparator = appHostArgList.Select((a, i) => (index: i, value: a.Value))
    .FirstOrDefault(x => x.value == DotnetToolResourceExtensions.ArgumentSeparator);

var args = appHostArgList.Select((a, i) => (arg: a, display: i > argSeparator.index));

When there's no -- in the list, FirstOrDefault returns default — (index: 0, value: null) — so i > 0 hides argument 0. Reachable whenever the tool annotation has been removed (BuildToolExecArguments returns early and emits no separator) but the resource still has args. A structural count can't drift this way, so it goes away on migration.

Summary of what's left for #18904

• The additive, user-facing WithXyzArgs layer (WithToolArgs, WithCargoArgs, …)
• A framework-emitted segment separator, so integrations stop hand-rolling --
• DotnetToolResource migrating off the textual -- scan
• A decision on Go's WithAppArgs now that plain WithArgs does the right thing there

Happy to fold any of that into this PR instead if you'd rather see the whole shape at once — I kept it out to keep this one reviewable and behavior-preserving.

[Karol Zadora-Przylecki (karolz-ms)]

Doing final code review check...

[Karol Zadora-Przylecki (karolz-ms)]

Found one correctness issue in cross-consumer launch-tool argument composition.

[Karol Zadora-Przylecki (karolz-ms)]

Reviewed the current state of the branch (HEAD 7116888), skipping items already raised and addressed in earlier threads.

2 findings: 1 correctness bug, 1 test-coverage gap.

Everything else I traced checks out: FallbackExecutionTypes parity with the three removed preparation-time sites, restart cache invalidation for the new annotation (DcpExecutor.ForgetCachedCallbackResults), the manifest path (goes through ExecutionConfigurationBuilder, so it gets the prefix), the deliberate container skip, the DotnetToolResource built-in-invocation index scans, and the WithEntrypoint refactor in the Python integration.

[github-actions]

Tests selector (audit mode)

The full test matrix and all jobs still run in audit mode. The tests and jobs below are what selective CI would run under enforcement.

48 / 100 test projects · 4 jobs, from 26 changed files.

Selected test projects (48 / 100)

Aspire.EndToEnd.Tests, Aspire.Hosting.Analyzers.Tests, Aspire.Hosting.Azure.Kubernetes.Tests, Aspire.Hosting.Azure.Kusto.Tests, Aspire.Hosting.Azure.Tests, Aspire.Hosting.Blazor.Tests, Aspire.Hosting.Browsers.Tests, Aspire.Hosting.CodeGeneration.Go.Tests, Aspire.Hosting.CodeGeneration.Java.Tests, Aspire.Hosting.CodeGeneration.Python.Tests, Aspire.Hosting.CodeGeneration.Rust.Tests, Aspire.Hosting.CodeGeneration.TypeScript.Tests, Aspire.Hosting.Containers.Tests, Aspire.Hosting.DevTunnels.Tests, Aspire.Hosting.Docker.Tests, Aspire.Hosting.Dotnet.Tests, Aspire.Hosting.DotnetTool.Tests, Aspire.Hosting.EntityFrameworkCore.Tests, Aspire.Hosting.Foundry.Tests, Aspire.Hosting.Garnet.Tests, Aspire.Hosting.GitHub.Models.Tests, Aspire.Hosting.Go.Tests, Aspire.Hosting.JavaScript.Tests, Aspire.Hosting.Kafka.Tests, Aspire.Hosting.Keycloak.Tests, Aspire.Hosting.Kubernetes.Tests, Aspire.Hosting.Maui.Tests, Aspire.Hosting.Milvus.Tests, Aspire.Hosting.MongoDB.Tests, Aspire.Hosting.MySql.Tests, Aspire.Hosting.Nats.Tests, Aspire.Hosting.OpenAI.Tests, Aspire.Hosting.Oracle.Tests, Aspire.Hosting.Orleans.Tests, Aspire.Hosting.PostgreSQL.Tests, Aspire.Hosting.Python.Tests, Aspire.Hosting.Qdrant.Tests, Aspire.Hosting.RabbitMQ.Tests, Aspire.Hosting.Radius.Tests, Aspire.Hosting.Redis.Tests, Aspire.Hosting.RemoteHost.Tests, Aspire.Hosting.Seq.Tests, Aspire.Hosting.SqlServer.Tests, Aspire.Hosting.Testing.Tests, Aspire.Hosting.Tests, Aspire.Hosting.Valkey.Tests, Aspire.Hosting.Yarp.Tests, Aspire.Playground.Tests

Selected jobs (4)

deployment-e2e, extension-e2e, polyglot, typescript-api-compat

---

How these were chosen — grouped by what changed

⚠️ 38 of the 48 selected test projects come from a single change — src/Aspire.Hosting/ApplicationModel/ArgumentsExecutionConfigurationGatherer.cs.

🔧 src/Aspire.Hosting/ApplicationModel/ArgumentsExecutionConfigurationGatherer.cs (changed source)
→ 38 via the project graph

show 38

Aspire.Hosting.Analyzers.Tests (2 hops), Aspire.Hosting.Azure.Kubernetes.Tests (2 hops), Aspire.Hosting.Azure.Kusto.Tests (2 hops), Aspire.Hosting.Azure.Tests, Aspire.Hosting.Browsers.Tests (2 hops), Aspire.Hosting.CodeGeneration.Go.Tests, Aspire.Hosting.CodeGeneration.Java.Tests, Aspire.Hosting.CodeGeneration.Python.Tests, Aspire.Hosting.CodeGeneration.Rust.Tests, Aspire.Hosting.CodeGeneration.TypeScript.Tests, Aspire.Hosting.Containers.Tests (2 hops), Aspire.Hosting.DevTunnels.Tests (2 hops), Aspire.Hosting.Docker.Tests (2 hops), Aspire.Hosting.Garnet.Tests (2 hops), Aspire.Hosting.GitHub.Models.Tests (2 hops), Aspire.Hosting.JavaScript.Tests (2 hops), Aspire.Hosting.Kafka.Tests (2 hops), Aspire.Hosting.Keycloak.Tests (2 hops), Aspire.Hosting.Kubernetes.Tests (2 hops), Aspire.Hosting.Maui.Tests, Aspire.Hosting.Milvus.Tests (2 hops), Aspire.Hosting.MongoDB.Tests (2 hops), Aspire.Hosting.MySql.Tests (2 hops), Aspire.Hosting.Nats.Tests (2 hops), Aspire.Hosting.OpenAI.Tests (2 hops), Aspire.Hosting.Oracle.Tests (2 hops), Aspire.Hosting.Orleans.Tests (2 hops), Aspire.Hosting.PostgreSQL.Tests (2 hops), Aspire.Hosting.Qdrant.Tests (2 hops), Aspire.Hosting.RabbitMQ.Tests (2 hops), Aspire.Hosting.Redis.Tests (2 hops), Aspire.Hosting.RemoteHost.Tests, Aspire.Hosting.Seq.Tests (2 hops), Aspire.Hosting.SqlServer.Tests (2 hops), Aspire.Hosting.Testing.Tests (2 hops), Aspire.Hosting.Valkey.Tests (2 hops), Aspire.Hosting.Yarp.Tests (2 hops), Aspire.Playground.Tests

🧪 tests/Aspire.Hosting.Tests/Dcp/DcpExecutorTests.cs (changed test)
→ 1 directly: Aspire.Hosting.Tests
→ 2 via the project graph: Aspire.Hosting.Blazor.Tests, Aspire.Hosting.Radius.Tests

🔧 src/Aspire.Hosting.Python/PythonAppResourceBuilderExtensions.cs (changed source)
→ 1 directly: Aspire.Hosting.Python.Tests
→ 1 via the project graph: Aspire.Hosting.Foundry.Tests

📦 affected project Aspire.Hosting
→ 1 test: Aspire.EndToEnd.Tests

🔧 src/Aspire.Hosting.Dotnet/DotnetProjectHostingExtensions.cs (changed source)
→ 1 directly: Aspire.Hosting.Dotnet.Tests

🔧 src/Aspire.Hosting.EntityFrameworkCore/EFResourceBuilderExtensions.cs (changed source)
→ 1 directly: Aspire.Hosting.EntityFrameworkCore.Tests

🔧 src/Aspire.Hosting.Go/GoHostingExtensions.cs (changed source)
→ 1 directly: Aspire.Hosting.Go.Tests

🧪 tests/Aspire.Hosting.Dotnet.Tests/DotnetProjectResourceTests.cs (changed test)
→ 1 directly: Aspire.Hosting.Dotnet.Tests

🧪 tests/Aspire.Hosting.DotnetTool.Tests/AddDotnetToolTests.cs (changed test)
→ 1 directly: Aspire.Hosting.DotnetTool.Tests

🧪 tests/Aspire.Hosting.EntityFrameworkCore.Tests/EFCoreOperationExecutorTests.cs (changed test)
→ 1 directly: Aspire.Hosting.EntityFrameworkCore.Tests

🧪 tests/Aspire.Hosting.Go.Tests/AddGoAppTests.cs (changed test)
→ 1 directly: Aspire.Hosting.Go.Tests

🧪 tests/Aspire.Hosting.Python.Tests/AddPythonAppTests.cs (changed test)
→ 1 directly: Aspire.Hosting.Python.Tests

🧪 tests/Aspire.Hosting.Tests/ExecutableResourceBuilderExtensionTests.cs (changed test)
→ 1 directly: Aspire.Hosting.Tests

🧪 tests/Aspire.Hosting.Tests/ResourceDependencyTests.cs (changed test)
→ 1 directly: Aspire.Hosting.Tests

Job reasons

Job	Triggered by
deployment-e2e	affected project Aspire.Hosting.Azure
extension-e2e	• src/Aspire.Hosting.Dotnet/DotnetProjectHostingExtensions.cs, src/Aspire.Hosting.EntityFrameworkCore/EFResourceBuilderExtensions.cs, src/Aspire.Hosting.Go/GoHostingExtensions.cs, src/Aspire.Hosting.Python/PythonAppResourceBuilderExtensions.cs, src/Aspire.Hosting/ApplicationModel/ArgumentsExecutionConfigurationGatherer.cs, src/Aspire.Hosting/ApplicationModel/DebugSupportExtensions.cs, src/Aspire.Hosting/ApplicationModel/ExecutableLaunchConfiguration.cs, src/Aspire.Hosting/ApplicationModel/ExecutionConfigurationGathererContext.cs, src/Aspire.Hosting/ApplicationModel/LaunchToolArgsCallbackAnnotation.cs, src/Aspire.Hosting/ApplicationModel/ProjectLaunchArgsOverrideAnnotation.cs, src/Aspire.Hosting/ApplicationModel/ResourceExtensions.cs, src/Aspire.Hosting/Aspire.Hosting.csproj, src/Aspire.Hosting/CompatibilitySuppressions.xml, src/Aspire.Hosting/Dcp/DcpExecutor.cs, src/Aspire.Hosting/Dcp/ExecutableCreator.cs, src/Aspire.Hosting/DotnetToolResourceExtensions.cs, src/Aspire.Hosting/ResourceBuilderExtensions.cs, src/Aspire.Hosting/SupportsDebuggingAnnotation.cs • affected project Aspire.Hosting.Dotnet
polyglot	affected project Aspire.Hosting.Go
typescript-api-compat	affected project Aspire.Hosting.Dotnet

---

Selection computed for commit 6f422aa.

[Copilot]

Pull request overview

Copilot reviewed 26 out of 26 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/Aspire.Hosting/ResourceBuilderExtensions.cs:4810

• The new public fluent API has no <example>/<code> block, despite the PR checklist marking that documentation complete. Its replacement and launch-configuration ownership semantics are non-obvious, so add a compilable example that shows the tool prefix and matching WithDebugSupport type.

    /// </remarks>

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[Karol Zadora-Przylecki (karolz-ms)]

/backport to release/13.5

[github-actions]

Started backporting to release/13.5 (link to workflow run)

[aspire-repo-bot]

Pull request created: #1458

Generated by PR Documentation Check · auto · 81.4 AIC · ⌖ 10.2 AIC · ⊞ 19.4K

[aspire-repo-bot]

📝 Documentation has been drafted in microsoft/aspire.dev#1458 targeting release/13.5.

Updated the ASPIREEXTENSION001 diagnostic docs page to list the new WithLaunchToolArgs experimental API alongside WithDebugSupport/SupportsDebuggingAnnotation, with a brief explanation of how it separates launch-tool ("entrypoint") arguments from ordinary WithArgs arguments.

• Modified: src/frontend/src/content/docs/diagnostics/aspireextension001.mdx

Note

This draft PR needs human review before merging.