Expose the evaluated project assembly name for debugger attach

[Adam Ratzman (adamint)]

Description

A .NET project resource is launched as dotnet run <project>, so the PID Aspire reports belongs to the dotnet run launcher rather than to the worker process a debugger actually wants to attach to. A consumer that wants to find the worker among the launcher's children has nothing reliable to match on: the project file name is often not the assembly name, because AssemblyName is frequently set in an imported Directory.Build.props rather than in the project file itself.

This exposes the MSBuild-evaluated assembly name so a consumer can match <AssemblyName>.dll / <AssemblyName> among the descendant processes.

How it works

• IProjectMetadata gains string? AssemblyName => null as a default interface member, matching the existing SuppressBuild and IsFileBasedApp DIMs. Path-based metadata, file-based apps, and third-party implementations stay source and binary compatible and simply return null.
• The AppHost SDK targets resolve each project resource's evaluated assembly name at AppHost build time and bake it into the generated IProjectMetadata class. Nothing runs at application run time.
• At run time ResourceSnapshotBuilder writes a project.assemblyName snapshot property only when a name resolved. Absence is the capability signal, so a consumer can tell "no name available" from "name is empty".
• SkipAspireProjectResourceAssemblyName=true opts out.

The probe uses the SDK's own two-phase idiom: GetTargetFrameworks to pick a TFM, then GetTargetPath to get the built output path, deriving the name from that path. It runs over prepared references (_MSBuildProjectReferenceExistent) so it inherits the same configuration, platform, and global-property removals the SDK already computed for each reference. Because ResolveProjectReferences already asks for GetTargetPath with the same effective global properties, MSBuild serves the probe's request from its result cache.

Measured cost: exactly one extra GetTargetFrameworks call per project reference, and zero extra GetTargetPath calls. I verified this with an instrumented probe-counting harness rather than assuming it.

This does not close #18602. Replicas and descendant PIDs still need a DCP-side contract; this is the smaller, self-contained half.

Fixes #18937

Validation

Check	Result
Aspire.Hosting.Sdk.Tests *.ProjectMetadata*	12/12 pass
Aspire.Hosting.Tests ResourceSnapshotBuilderTests + ProjectResourceBuilderExtensionTests	31/31 pass
Aspire.Dashboard.Tests ResourceViewModelTests + KnownPropertyLookupTests + ResourceSnapshotMapperTests	48/48 pass
Real dotnet build of tests/testproject/TestProject.AppHost	0 warnings, 0 errors
Generated metadata for all 5 project references, incl. a cross-TFM net8.0→net9.0 reference	correct AssemblyName
playground/DotnetProject/DotnetProject.AppHost	builds clean

The SDK tests cover assembly names arriving from an imported Directory.Build.props, Configuration- and TargetFramework-conditioned values, per-reference SetConfiguration/SetPlatform, solution-prepared references, GlobalPropertiesToRemove, multi-targeted references, C# escaping of exotic names, and the opt-out.

Review notes

This went through a 4-lane review panel plus an incremental re-review. Things worth knowing:

• A design-time-build skip was implemented and then reverted. Suppressing the metadata write during design-time builds froze the entire generated file, so an unrelated change (a moved ProjectPath, AspireProjectMetadataTypeName, AspireGeneratedClassesVisibility) would go stale in the IDE until a real build. That regression was not worth the ~1 cheap target per reference it saved.
• Probe failures are fatal during a real build (ContinueOnError="!$(BuildingProject)"), matching _ValidateAspireHostProjectResources in the same file and the SDK's own GetTargetFrameworks/GetTargetPath calls. The re-review caught that this path was never exercised — every SDK test uses a bare -t: invocation, which never runs BuildOnlySettings — so there is now a test that forces BuildingProject=true, plus the real dotnet build above.
• The probe is skipped for the AppHost server project the CLI generates. Its ProjectReferences are Aspire.Hosting.* libraries, not app resources anyone attaches a debugger to.

Findings I declined, with rationale:

• First TFM is used for multi-targeted references. A wrong name leaves a consumer exactly where omission would — falling back to its own guess — while the common case (all TFMs produce the same name) resolves correctly. A TFM-conditioned AssemblyName on a multi-targeted executable project resource is vanishingly rare. Recorded in a comment in the targets file.
• RemoveProperties is duplicated with _ValidateAspireHostProjectResources. That target consumes raw _AspireProjectResource items rather than prepared references and is skipped in-repo, so refactoring it carries more risk than value.
• VS fast-up-to-date-check may not notice a worker-only AssemblyName change. WriteAspireProjectMetadataSources runs BeforeTargets="CoreCompile" on every dotnet build, so the gap is VS FUTDC only.

Deferred as a follow-up: the SDK targets tests each spawn dotnet msbuild -restore, which is real CI cost, but that is pre-existing harness design rather than something this PR introduced.

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
  • 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 -- 19136

Or

• Run remotely in PowerShell:

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

[Adam Ratzman (adamint)]

Review record

Posting as a comment rather than a review since this is my own PR.

Scope: Full review, 4 lanes (public API surface, hosting core, packaging/SDK targets, cross-platform), followed by one incremental re-review over the fix delta.

Fixed

Severity	Finding	Resolution
HIGH ×3 lanes	Skipping the metadata write during design-time builds froze the entire generated file, so a moved ProjectPath, an AspireProjectMetadataTypeName change, or an AspireGeneratedClassesVisibility change would go stale in the IDE until a real build. A regression unrelated to this feature.	Design-time skip fully reverted. Verified no DesignTimeBuild reference survives anywhere in the feature diff.
MEDIUM	ContinueOnError="true" silently swallowed probe failures, so a genuinely broken reference produced metadata with no assembly name and no diagnostic.	Both <MSBuild> calls now use ContinueOnError="!$(BuildingProject)", matching _ValidateAspireHostProjectResources in the same file and the SDK's own GetTargetFrameworks/GetTargetPath calls.
MEDIUM	The strict path above was never exercised — every SDK test uses a bare -t: invocation, which never runs BuildOnlySettings, so BuildingProject stayed false and the probe ran tolerant in all of them. Caught by the re-review.	Added a test forcing -p:BuildingProject=true, plus a real dotnet build of TestProject.AppHost (0 warnings, 0 errors).
MEDIUM	Unreachable dashboard legacy metadata. The dashboard resolves project.assemblyName through producer-supplied metadata the AppHost already sends, so the LegacyResourcePropertyMetadata arm and its localized string were dead on arrival — project.assemblyName never existed before this PR, so there is no older producer to be compatible with.	Deleted the switch arm, the resx entry, the Designer property, all 13 .xlf entries, and the corresponding test InlineData. src/Aspire.Dashboard/ now has zero net diff.
MEDIUM	Weak Assert.Empty(...Where(...)) assertions in the two "omits assembly name" tests — proved absence without verifying what is present.	Replaced with full Assert.Equal property-set assertions. This immediately caught two resource properties missing from my expected sets.
LOW–MED	The CLI-generated AppHost server project is built by a real dotnet build and defaults its Aspire.Hosting.* ProjectReferences to IsAspireProjectResource=true, so the newly-strict probe would run over multi-targeted libraries nobody attaches a debugger to.	Set SkipAspireProjectResourceAssemblyName=true there, alongside the SkipValidateAspireHostProjectResources already present for the same reason.
LOW	Ambient central package management could leak into the SDK test workspace.	Harness now writes Directory.Packages.props with ManagePackageVersionsCentrally=false.
LOW	SkipAspireProjectResourceAssemblyName undocumented.	Documented inline in the targets header. There is no docs file for AppHost MSBuild properties and the sibling Skip* switches are also undocumented, so I did not invent a new convention for one property.

Disproved

One lane raised a HIGH claiming the probe added a duplicate GetTargetPath sweep across every reference. I built an instrumented harness that counts target invocations. Measured: one extra GetTargetFrameworks per reference, zero extra GetTargetPath — ResolveProjectReferences already requests GetTargetPath with the same effective global properties, so MSBuild serves the probe from its result cache. The finding was withdrawn and the measured numbers are now recorded in a comment in the targets file.

An earlier premise that the probe needed protection from warnaserror was also disproved: a normal build already invokes GetTargetPath on these same references, so the probe adds no new failure surface. The settings-splitting machinery built for that premise was deleted.

Declined, with rationale

• First TFM for multi-targeted references. A wrong name leaves a consumer exactly where omission would — falling back to its own guess — while the common case (all TFMs produce the same name) resolves correctly. A TFM-conditioned AssemblyName on a multi-targeted executable project resource is vanishingly rare. Recorded in a targets comment.
• Duplicated RemoveProperties string shared with _ValidateAspireHostProjectResources. That target consumes raw _AspireProjectResource items rather than prepared references and is skipped in-repo; refactoring it carries more risk than value.
• VS fast-up-to-date-check may not see a worker-only AssemblyName change. Narrowed considerably by the design-time revert: WriteAspireProjectMetadataSources runs BeforeTargets="CoreCompile" on every dotnet build, so the gap is VS FUTDC only.

Deferred

The SDK targets tests each spawn dotnet msbuild -restore under a hard 3-minute cap — real CI cost, but pre-existing harness design rather than something this PR introduced.

Known constraint worth recording

The probe target must stay pure MSBuild. _AspireTasksAssembly points at Aspire.Hosting.Tasks.dll, which only exists in the packed NuGet package, not in the repo. UsingTask is lazy so declaring a task is harmless, but invoking one from the unconditional WriteAspireProjectMetadataSources path breaks every in-repo AppHost with MSB4062. An early iteration hit exactly this.

[Copilot]

Pull request overview

Exposes MSBuild-evaluated project assembly names for debugger process matching.

Changes:

• Adds optional IProjectMetadata.AssemblyName.
• Resolves names during AppHost builds and exposes project.assemblyName.
• Adds dashboard metadata, localization, and cross-layer tests.

Show a summary per file

File	Description
tests/Aspire.Hosting.Tests/ProjectResourceBuilderExtensionTests.cs	Tests default and path-based metadata.
tests/Aspire.Hosting.Tests/Dcp/ResourceSnapshotBuilderTests.cs	Tests snapshot assembly-name behavior.
tests/Aspire.Hosting.Sdk.Tests/AppHostSdkTargetsTests.cs	Tests MSBuild evaluation scenarios.
tests/Aspire.Dashboard.Tests/Model/KnownPropertyLookupTests.cs	Tests property lookup.
tests/Aspire.Cli.Tests/Backchannel/ResourceSnapshotMapperTests.cs	Tests backchannel serialization.
src/Shared/Model/KnownProperties.cs	Defines the snapshot property key.
src/Aspire.Hosting/Resources/xlf/MessageStrings.zh-Hant.xlf	Updates localization resources.
src/Aspire.Hosting/Resources/xlf/MessageStrings.zh-Hans.xlf	Updates localization resources.
src/Aspire.Hosting/Resources/xlf/MessageStrings.tr.xlf	Updates localization resources.
src/Aspire.Hosting/Resources/xlf/MessageStrings.ru.xlf	Updates localization resources.
src/Aspire.Hosting/Resources/xlf/MessageStrings.pt-BR.xlf	Updates localization resources.
src/Aspire.Hosting/Resources/xlf/MessageStrings.pl.xlf	Updates localization resources.
src/Aspire.Hosting/Resources/xlf/MessageStrings.ko.xlf	Updates localization resources.
src/Aspire.Hosting/Resources/xlf/MessageStrings.ja.xlf	Updates localization resources.
src/Aspire.Hosting/Resources/xlf/MessageStrings.it.xlf	Updates localization resources.
src/Aspire.Hosting/Resources/xlf/MessageStrings.fr.xlf	Updates localization resources.
src/Aspire.Hosting/Resources/xlf/MessageStrings.es.xlf	Updates localization resources.
src/Aspire.Hosting/Resources/xlf/MessageStrings.de.xlf	Updates localization resources.
src/Aspire.Hosting/Resources/xlf/MessageStrings.cs.xlf	Updates localization resources.
src/Aspire.Hosting/Resources/MessageStrings.resx	Adds the display-name resource.
src/Aspire.Hosting/Resources/MessageStrings.Designer.cs	Exposes the generated resource accessor.
src/Aspire.Hosting/IProjectMetadata.cs	Adds optional assembly-name metadata.
src/Aspire.Hosting/Dcp/ResourceSnapshotBuilder.cs	Publishes the snapshot property.
src/Aspire.Hosting/Dashboard/ResourcePropertySnapshotMetadata.cs	Configures dashboard presentation.
src/Aspire.Hosting.AppHost/build/Aspire.Hosting.AppHost.in.targets	Evaluates and generates assembly metadata.
src/Aspire.Cli/Projects/DotNetBasedAppHostServerProject.cs	Opts generated server projects out.

Review details

Files not reviewed (1)

• src/Aspire.Hosting/Resources/MessageStrings.Designer.cs: Generated file

• Files reviewed: 25/26 changed files
• Comments generated: 1
• Review effort level: Balanced

[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.

[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.

[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]

Review details

Files not reviewed (1)

• src/Aspire.Hosting/Resources/MessageStrings.Designer.cs: Generated file

Suppressed comments (2)

tests/Aspire.Hosting.Sdk.Tests/AppHostSdkTargetsTests.cs:338

• This test does not exercise the failure path it claims to cover. Setting BuildingProject=true only changes ContinueOnError; the generated worker still lets both probes succeed, so this test would also pass if failures were accidentally tolerated. Inject a failing BeforeTargets="GetTargetPath" (or equivalent probe failure) and assert that the MSBuild invocation exits nonzero when BuildingProject=true.

        // The probe passes ContinueOnError="!$(BuildingProject)", so a real build makes a failed
        // reference probe fatal while a design-time build stays tolerant. Every other test here runs
        // a bare -t: invocation, which never executes BuildOnlySettings and therefore leaves
        // BuildingProject at its default of false. Forcing it to true covers the strict path.

src/Aspire.Hosting.AppHost/build/Aspire.Hosting.AppHost.in.targets:115

• A wrong non-empty value does not leave consumers in the same state as omission. The attach consumer prefers reportedAssemblyName with ??, so a first-TFM name shadows its fallback even if the IDE launches another TFM whose conditioned AssemblyName differs. For a cross-targeting reference without SetTargetFramework, omit this property unless the selected launch TFM is known (or all TFMs resolve to the same name).

      %(TargetFrameworks) is a single semicolon-joined value such as "net8.0;net9.0"; the first entry is used because
      it is the one a cross-targeting reference reports first and Aspire never negotiates a TFM for these references,
      so there is no better signal about which inner build the AppHost will end up launching. Guessing is worth it
      here: a name resolved from the wrong inner build leaves a consumer exactly where omitting the property would
      have - falling back to its own guess - while the common case, where every TFM produces the same assembly name,
      resolves correctly.

• Files reviewed: 25/26 changed files
• Comments generated: 0 new
• Review effort level: Balanced

[Copilot]

Review details

Files not reviewed (1)

• src/Aspire.Hosting/Resources/MessageStrings.Designer.cs: Generated file

Suppressed comments (3)

tests/Aspire.Hosting.Sdk.Tests/AppHostSdkTargetsTests.cs:335

• This test never makes either probe fail; it only verifies that a successful probe also succeeds with BuildingProject=true. Changing both ContinueOnError values to always tolerate failures would still pass, so the newly introduced fatal-build behavior is not covered. Add a referenced target that deliberately errors during GetTargetFrameworks or GetTargetPath and assert a nonzero build result when BuildingProject=true.

    public async Task ProjectMetadataResolvesAssemblyNameWhenProbeFailuresAreFatal()
    {
        using var workspace = TemporaryWorkspace.Create(outputHelper);

        // The probe passes ContinueOnError="!$(BuildingProject)", so a real build makes a failed

src/Aspire.Hosting/IProjectMetadata.cs:48

• The remarks incorrectly state that third-party implementations return null. Existing implementations inherit that default, but new or updated implementations can override this member, and ResourceSnapshotBuilder consumes such values from any IProjectMetadata. Document the default behavior without excluding custom providers.

    /// Implementations that are not produced by the AppHost build - for example metadata created from a project
    /// path at runtime, file-based apps, or third-party implementations - return <see langword="null"/>. Consumers
    /// must therefore treat the value as an optional hint and fall back to their existing behavior when it is absent.

src/Shared/Model/KnownProperties.cs:62

• This property is not restricted to ProjectReference resources. ResourceSnapshotBuilder emits it for any IProjectMetadata implementation that supplies a nonblank value, including annotation-based/custom resources. The comment should describe generated metadata as one provider rather than claiming exclusivity.

        /// The MSBuild-evaluated assembly name of the project, baked into the generated project metadata at
        /// AppHost build time. Only present for project resources added through a ProjectReference; the absence
        /// of the property is the signal that the producer could not determine the name.

• Files reviewed: 26/27 changed files
• Comments generated: 1
• Review effort level: Balanced

[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.

[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.

[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]

Review details

Files not reviewed (1)

• src/Aspire.Hosting/Resources/MessageStrings.Designer.cs: Generated file

Suppressed comments (1)

tests/Aspire.Hosting.Sdk.Tests/AppHostSdkTargetsTests.cs:355

• This test never makes either GetTargetFrameworks or GetTargetPath fail, so ContinueOnError is never exercised; it would still pass if both probe calls were changed to always continue. Since real-build probe failures are intentionally build-fatal, add a case whose referenced project emits an error from one of those probe targets and assert that BuildingProject=true produces a nonzero MSBuild exit code (and, ideally, that the tolerant mode continues).

    public async Task ProjectMetadataResolvesAssemblyNameWhenProbeFailuresAreFatal()

• Files reviewed: 26/27 changed files
• Comments generated: 0 new
• Review effort level: Balanced

[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.

[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.

[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]

Review details

Files not reviewed (1)

• src/Aspire.Hosting/Resources/MessageStrings.Designer.cs: Generated file

Suppressed comments (1)

tests/Aspire.Hosting.Sdk.Tests/AppHostSdkTargetsTests.cs:425

• This test does not exercise the claimed fatal-failure path: both probes succeed, so BuildingProject=true has no observable effect and the test would still pass if ContinueOnError were always enabled. Make one referenced target fail and assert that the MSBuild invocation exits nonzero in strict mode (and, if desired, remains tolerant when BuildingProject=false).

    public async Task ProjectMetadataResolvesAssemblyNameWhenProbeFailuresAreFatal()
    {
        using var workspace = TemporaryWorkspace.Create(outputHelper);

        // The probe passes ContinueOnError="!$(BuildingProject)", so a real build makes a failed

• Files reviewed: 26/27 changed files
• Comments generated: 1
• Review effort level: Balanced

[Copilot]

Review details

Files not reviewed (1)

• src/Aspire.Hosting/Resources/MessageStrings.Designer.cs: Generated file

Suppressed comments (1)

tests/Aspire.Hosting.Sdk.Tests/AppHostSdkTargetsTests.cs:428

• This test never causes either probe to fail, so ContinueOnError is not exercised: it would pass unchanged if the production value were hard-coded to either true or false. Since the new real-build behavior intentionally makes probe failures fatal, inject a referenced-project target that fails during GetTargetFrameworks/GetTargetPath and assert a non-zero build result with BuildingProject=true (ideally paired with the tolerant case).

        // The probe passes ContinueOnError="!$(BuildingProject)", so a real build makes a failed
        // reference probe fatal while a design-time build stays tolerant. Every other test here runs
        // a bare -t: invocation, which never executes BuildOnlySettings and therefore leaves
        // BuildingProject at its default of false. Forcing it to true covers the strict path.

• Files reviewed: 26/27 changed files
• Comments generated: 0 new
• Review effort level: Balanced

[Copilot]

Review details

Files not reviewed (1)

• src/Aspire.Hosting/Resources/MessageStrings.Designer.cs: Generated file

Suppressed comments (2)

tests/Aspire.Hosting.Sdk.Tests/AppHostSdkTargetsTests.cs:445

• This test never makes either MSBuild probe fail; the helper asserts a zero exit code and the test only proves that a successful probe still works with BuildingProject=true. It would continue passing if the fatal ContinueOnError behavior regressed. Trigger a failing GetTargetFrameworks or GetTargetPath probe and assert that the real-build invocation exits nonzero (and, if the tolerant path is part of the contract, that the design-time invocation continues).

    public async Task ProjectMetadataResolvesAssemblyNameWhenProbeFailuresAreFatal()

src/Aspire.Hosting.AppHost/build/Aspire.Hosting.AppHost.in.targets:134

• The tests added here all create a single project reference, so this per-item pairing logic is not exercised with multiple references. A batching regression that applies one reference's framework/name metadata to another would still pass, even though multi-project AppHosts are the normal case. Add a test with at least two references having distinct assembly names and assert each generated metadata file receives its own value.

      The item list is updated from itself on purpose. Updating one list from another (Update="@(OtherList)") does not
      batch per item - the last batch's values are applied to every item - so the self-update is what keeps each
      reference's TargetFrameworks metadata paired with its own project.

• Files reviewed: 26/27 changed files
• Comments generated: 0 new
• Review effort level: Balanced