Multi-targeted AppHost fails to build: error MSB4036: The "Microsoft.NET.Build.Tasks.PickBestRid" task was not found

[bording]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

With Aspire 13.4, when the the AppHost is multi-targeted (TargetFrameeworks property used instead of TargetFramework), the project fails to build because of a missing task:

F:\.nuget\packages\aspire.apphost.sdk\13.4.2\Sdk\Sdk.targets(143,5): error MSB4036: The "Microsoft.NET.Build.Tasks.PickBestRid" task was not found. Check the following: 1.) The name of the task in the project file is the same as the name of the task class. 2.) The task class is "public" and implements the Microsoft.Build.Framework.ITask interface. 3.) The task is correctly declared with <UsingTask> in the project file, or in the *.tasks files located in the "C:\Program Files\dotnet\sdk\10.0.300" directory.

This works fine with the latest 13.3 version

Expected Behavior

I expect the AppHost to be able to build when it is multi-targeted.

Steps To Reproduce

1. dotnet new aspire-apphost
2. In the .csproj, change <TargetFramework>net10.0</TargetFramework> to <TargetFrameworks>net10.0</TargetFrameworks>
3. dotnet build

Exceptions (if any)

Build error:

F:\.nuget\packages\aspire.apphost.sdk\13.4.2\Sdk\Sdk.targets(143,5): error MSB4036: The "Microsoft.NET.Build.Tasks.PickBestRid" task was not found. Check the following: 1.) The name of the task in the project file is the same as the name of the task class. 2.) The task class is "public" and implements the Microsoft.Build.Framework.ITask interface. 3.) The task is correctly declared with <UsingTask> in the project file, or in the *.tasks files located in the "C:\Program Files\dotnet\sdk\10.0.300" directory.

Aspire doctor output

Aspire Environment Check

Aspire
✅ Aspire CLI version 13.4.2 (channel: stable)

AppHost
⚠️ Could not determine AppHost version (repro.csproj)

.NET SDK
✅ .NET 10.0.300 installed (x64)

Container Runtime
✅ Docker v29.5.2: running (auto-detected (default)) ← active

Environment
✅ HTTPS development certificate is trusted

Summary: 4 passed, 1 warnings, 0 failed

Anything else?

No response

[joperezr]

🤖 Aspire triage pass — 2026-06-04 20:50 UTC

Area: area-app-model
Kind: regression
Repro: yes-minimal — see "Steps To Reproduce" in the issue body (3 short steps)
Affected version(s): 13.4.2 broken (last working: 13.3.x — reporter states "works fine with the latest 13.3 version"; latest stable: 13.4.2)
Severity: S2 — multi-targeted AppHost build is completely broken on 13.4 with no workaround other than abandoning multi-targeting

Urgency: 🔴 servicing — recommend milestone 13.4.x
Reason: Regression introduced in 13.4. The Microsoft.NET.Build.Tasks.PickBestRid task usage was added to src/Aspire.AppHost.Sdk/SDK/Sdk.in.targets in #17259 ("Optimize AppHost RID selection", merged 2026-05-19 for 13.4) and breaks the multi-target build path that worked in 13.3.x. No workaround for users who legitimately need <TargetFrameworks>.

Suggested owner(s): @davidfowl (score 11), backup @mitchdenny (score 6)
Evidence:

• davidfowl authored the suspected regressing PR Optimize AppHost RID selection #17259 ("Optimize AppHost RID selection") which is the only recent merged PR touching src/Aspire.AppHost.Sdk/SDK/Sdk.in.targets — the exact targets file in the error
• davidfowl also merged Delegate bundled AppHost dotnet run to Aspire CLI #17748, Fix VS Code AppHost launch path resolution #17408 in the AppHost area in the last 30d
• mitchdenny merged Fix 13.4 staging CLI dropping nuget.config without Aspire package source mapping #17528, Reconcile orphan Aspire.Hosting.AppHost references when SDK is already current #17016, Fix #15986: emit apphost.run.json from aspire init single-file skeleton #16812 in AppHost / SDK adjacent areas (last 30d)
• CODEOWNERS for /src/Aspire.Hosting lists @JamesNK @karolz-ms @danegsta @mitchdenny @davidfowl (no explicit owner for /src/Aspire.AppHost.Sdk)

Confidence: high
Needs human?: yes — 13.4.x recommendation requires human confirmation (servicing regression)

Dry-run mode — no labels or milestone applied. Reply /triage apply to promote, or edit and reapply.

[davidfowl]

Why is your apphost multitargeted?

[bording]

Why is your apphost multitargeted?

We have samples on our documentation site, and we offer downloads for all of the .NET versions that are supported by a given version of our product (NServiceBus). For example, here is our Aspire sample: https://docs.particular.net/samples/hosting/aspire/?version=core_9

The end result is that we offer separate downloads for each .NET version, but the way that is done is by multi-targeting the sample project:

So, we need to be able to multi-target, and it's been working fine right up until 13.4.

[davidfowl]

FWIW we will fix the issue but why have 3 downloads and multitarget?

[bording]

FWIW we will fix the issue but why have 3 downloads and multitarget?

It's how we author content for our documentation site. We multi-target the sample project to identify which .NET versions we want to offer for download. Then, when the content repo is processed to turn it into the final content output, each sample project is transformed into separate, single-targeted zip files for downloading.

It might seem a bit convoluted, but it really cuts down on the amount of work involved in creating and maintaining our samples.