feat(aspire): add TUnit.Aspire.Core without TUnit metapackage dependency (#5471)

[thomhurst]

Problem

Referencing TUnit.Aspire pulls in the TUnit metapackage, which sets IsTestProject / OutputType=Exe via the convention-packed build/TUnit.props. Those properties propagate to any consumer, so a shared test-infrastructure library that references TUnit.Aspire gets wrongly flagged as a test project. Reported in discussion #5471 (and matches the earlier TUnit.AspNetCore fix in #5474).

Fix

Mirror the existing TUnit.AspNetCore / TUnit.AspNetCore.Core split:

• New TUnit.Aspire.Core — holds all code, references only TUnit.Core + TUnit.OpenTelemetry. RootNamespace stays TUnit.Aspire, so public types keep their namespace.
• TUnit.Aspire becomes a thin metapackage — references TUnit + TUnit.Aspire.Core, no source. Non-breaking: existing consumers keep the same public surface and transitively get .Core.
• TUnit.OpenTelemetry grants InternalsVisibleTo to TUnit.Aspire.Core (AspireFixture consumes the internal OtlpReceiver).
• Registered TUnit.Aspire.Core in all three .slnx files.
• Documented in docs/examples/aspire.md: shared infra libs should reference TUnit.Aspire.Core.

How to use

# Test projects (unchanged):
dotnet add package TUnit.Aspire

# Shared test-infrastructure libraries (new — won't be flagged as a test project):
dotnet add package TUnit.Aspire.Core

Verification

• TUnit.Aspire, TUnit.Aspire.Core, and TUnit.Aspire.Tests all build clean on net10.0 (0 warn / 0 err). The test project exercises the InternalsVisibleTo wiring (OtlpReceiver from OTel, OtlpEndpointEnvironment from .Core).
• The 5 .cs files are pure git renames (0 content change).

Follow-ups (not in this PR)

• Same latent issue exists in TUnit.Playwright and TUnit.FsCheck (both reference the TUnit metapackage with no .Core twin).
• Deeper fix raised in Add TUnit.AspNetCore.Core that does not depend on the TUnit metapackage? #5471: gate the IsTestProject block in build/TUnit.props so it doesn't propagate transitively, so only direct consumers of TUnit become test projects. Larger change to the packaging contract — deferred.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[claude]

Code Review

This is a clean, well-structured fix that faithfully mirrors the existing TUnit.AspNetCore / TUnit.AspNetCore.Core split. The approach is correct and the implementation is tight. A few minor observations and one potential gap worth noting:

What's done well

• The 5 source files are pure renames with zero content change — a good sanity check.
• RootNamespace is preserved on TUnit.Aspire.Core, so all public types keep their existing namespace and no consuming code needs changes.
• The InternalsVisibleTo graph is correct: TUnit.OpenTelemetry now grants access to TUnit.Aspire.Core (instead of TUnit.Aspire), and TUnit.Aspire.Core grants access to both TUnit.Aspire and TUnit.Aspire.Tests.
• The SupportedPlatform Remove="browser" block has been correctly moved to TUnit.Aspire.Core since that's where the server-side Aspire code now lives.
• TUnit.Aspire correctly retains the TUnit.Analyzers analyzer reference (as a thin metapackage that wires up the full toolchain for test projects), while TUnit.Aspire.Core only ships TUnit.Core.SourceGenerator — consistent with how TUnit.AspNetCore.Core handles this.
• All three .slnx files are updated.
• Documentation is updated with a clear tip and the right guidance.

One gap: TUnit.Aspire.Core has no package <Description>

TUnit.OpenTelemetry has a <Description> element in its csproj that shows up on NuGet. TUnit.Aspire.Core has none. This is a minor discoverability issue — a new package without a description is harder to find and evaluate on NuGet. Consider adding something like:

<Description>Core Aspire integration for TUnit — holds the fixtures and hooks without pulling in the TUnit metapackage. Use this in shared test-infrastructure libraries; use TUnit.Aspire in actual test projects.</Description>

This is not a blocker, but worth doing since the split introduces a new published package.

Confirmed non-issue: InternalsVisibleTo on TUnit.Aspire

TUnit.Aspire.Core grants InternalsVisibleTo to TUnit.Aspire. Since TUnit.Aspire is now a source-free metapackage (no .cs files, just project references), this entry has no practical effect today. It's harmless to leave it in — future-proofing if TUnit.Aspire ever grows its own source — but a comment like <!-- reserved; TUnit.Aspire is currently source-free --> would save the next reader from wondering whether it's load-bearing.

Follow-up noted in the PR description

The PR correctly calls out that TUnit.Playwright and TUnit.FsCheck have the same latent issue. The deeper fix (gating IsTestProject in build/TUnit.props to not propagate transitively) is the right long-term solution and deferring it is reasonable given the scope of that packaging-contract change.

Overall this is a solid, minimal change that solves the reported problem without any breaking surface changes. The pattern is already proven by the TUnit.AspNetCore split.

[claude]

Code Review

This is a clean, well-executed PR. The implementation precisely mirrors the established TUnit.AspNetCore / TUnit.AspNetCore.Core split pattern, and the core structure is correct. Reviewing against the previous claude[bot] feedback to check what's been addressed.

Previous review follow-up

<Description> in TUnit.Aspire.Core.csproj — the prior review suggested adding a NuGet description; it wasn't added. However, comparing against the pattern being mirrored: TUnit.AspNetCore.Core also lacks a <Description> element, so omitting it is internally consistent. That said, TUnit.OpenTelemetry does have one, and this is a new user-facing package. I'd lean toward adding one — e.g.:

<Description>Core Aspire integration for TUnit. References only TUnit.Core (not the TUnit metapackage), so shared test-infrastructure libraries can use Aspire fixtures without being flagged as test projects. Use TUnit.Aspire in actual test projects.</Description>

Not a blocker, but worth doing for discoverability since this is the package users would explicitly add to a shared lib.

What's correct and well-done

• Pure git renames for all 5 source files — zero content drift, so there's no risk of divergence between the new location and what was tested in the old one.
• RootNamespace remains TUnit.Aspire in TUnit.Aspire.Core.csproj, so all public types keep their existing namespace. Zero breaking change for consumers.
• InternalsVisibleTo graph is correctly rewired: TUnit.OpenTelemetry now grants access to TUnit.Aspire.Core (where AspireFixture consumes the internal OtlpReceiver), and TUnit.Aspire.Core grants access to both TUnit.Aspire (future-proofing) and TUnit.Aspire.Tests.
• TUnit.Aspire.Tests still retains InternalsVisibleTo from TUnit.OpenTelemetry (the unchanged line), so test coverage of OTel internals is unaffected.
• SupportedPlatform Remove="browser" correctly moved to TUnit.Aspire.Core — the server-side Aspire code is now there.
• All three .slnx files updated, public API snapshot files updated correctly.
• Documentation updated with clear guidance on when to use TUnit.Aspire.Core vs TUnit.Aspire.
• TUnit.Core.SourceGenerator included as an Analyzer in TUnit.Aspire.Core — correct since the relocated types use TUnit attributes.

Minor note: harmless no-op InternalsVisibleTo

TUnit.Aspire.Core grants InternalsVisibleTo Include="TUnit.Aspire", but TUnit.Aspire is now source-free (no .cs files). This has no effect today and is fine as forward-compatibility plumbing — a brief comment (as suggested previously) would save a future reader from wondering if it's load-bearing, but it's not required.

Overall

The PR solves a real problem cleanly, without any observable breaking surface changes. The structure is proven by the AspNetCore split. Approving — the only open item (missing <Description>) is a nice-to-have that can be addressed in a follow-up alongside TUnit.AspNetCore.Core for consistency.