Prevent recursive MTP test runner invocation - #20573
Conversation
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 20573Or
iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 20573" |
github-actions
Bot
added
the
needs-area-label
This comment has been minimized.
This comment has been minimized.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
Copilot review overview
🟢 Approval recommended
The focused guard prevents the reported recursion while preserving valid AppHost entry-point resolution with regression coverage.
Review effort: Balanced
Findings: None
What changed in this PR
Prevents recursive Microsoft.Testing.Platform test execution when resolving an AppHost entry point.
Changes:
- Detects MTP application metadata and fails with actionable guidance.
- Adds regression and valid-AppHost tests.
| File | Description |
|---|---|
src/Aspire.Hosting.Testing/DistributedApplicationEntryPointInvoker.cs |
Rejects MTP test application entry points. |
tests/Aspire.Hosting.Testing.Tests/DistributedApplicationEntryPointInvokerTests.cs |
Verifies rejection and normal AppHost resolution. |
💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.
|
Rather than blocking MTP, could we concretely detect an App Host assembly? Even with this fix, you could get a similar issue if you referenced a type from a Consle app. e.g. If the Aspire SDK adds a unique assembly marker to app hosts, could we look for that? |
This comment has been minimized.
This comment has been minimized.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Tests selector41 / 99 PR test projects · 1 PR job, from 3 changed files. Selected PR test projects (41 / 99)
Selected PR jobs (1)
How these were chosen — grouped by what changed
🔧 show 40
🔧 🧪 Job reasons
Selection computed for commit |
Updated to a more expansive check to look for the general shape of generated test project assemblies getting shadowed by the MTP test assembly. |
|
Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt. |
James Newton-King (JamesNK)
left a comment
James Newton-King (JamesNK)
left a comment
There was a problem hiding this comment.
Reviewed locally; no high-confidence issues found. Focused DistributedApplicationEntryPointInvokerTests passed: 4 passed, 0 failed.
Adds a troubleshooting section to the advanced testing scenarios page explaining why Aspire.AppHost.Sdk test projects can recursively invoke the test runner via DistributedApplicationTestingBuilder.CreateAsync, and how to fix it (Microsoft.NET.Sdk + ProjectReference, dynamic assembly loading, or DistributedApplicationTestingBuilder.Create()). Documents microsoft/aspire#20573 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
Pull request created: #1804
|
|
📝 Documentation has been drafted in microsoft/aspire.dev#1804 targeting Documents the new guard in Note This draft PR needs human review before merging. |
Description
DistributedApplicationTestingBuilder.CreateAsyncassumes the supplied type belongs to an AppHost executable and reflectively invokes that assembly's entry point. When a Microsoft.Testing.Platform test project is itself built withAspire.AppHost.Sdk, the generatedProjects.*type can instead belong to the test application. Invoking that assembly's entry point recursively starts the test runner, reruns the entire suite without the original filter, and can leave many AppHost and DCP processes active.Detect the
Microsoft.Testing.Platform.Application=trueassembly metadata before invoking the entry point and fail with a clear explanation. The diagnostic directs users to build test projects withMicrosoft.NET.Sdk, reference the AppHost project, or useDistributedApplicationTestingBuilder.Create()when no entry-point invocation is required. Using the assembly marker also covers test-framework wrappers such as xUnit's generated entry point.Validated with:
Fixes #20572
Related to #20568
Checklist
<remarks />and<code />elements on your triple slash comments?