fix(ci): restore net472 PublicAPI tests on Windows

[thomhurst]

Problem

The modularpipeline (windows-latest) job has failed on every PR since #6717. RunPublicAPITestsModule fails for net472 in three tests:

AssemblyResolutionException: Failed to resolve assembly: 'netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'
   at Mono.Cecil.BaseAssemblyResolver.Resolve(...)
   at PublicApiGenerator.AttributeFilter.ShouldIncludeAttribute(...)

Root cause

#6717 bumped Microsoft.Testing.Extensions.CodeCoverage from 18.10.0 to 18.11.2. The package reaches the project transitively through TUnit. Starting with 18.11, the package ships its own netstandard2.0 Mono.Cecil.dll in lib/. That file overwrites the net40 Mono.Cecil.dll from the Mono.Cecil package in the net472 output folder. I checked this by hash: the output file matches microsoft.testing.extensions.codecoverage/18.11.2/lib/netstandard2.0/Mono.Cecil.dll.

The netstandard2.0 build of Cecil can't resolve .NET Framework facades: it has no GAC or framework-directory lookup. So PublicApiGenerator can't resolve netstandard.

Fix

• In TUnit.PublicAPI, reference Microsoft.Testing.Extensions.CodeCoverage directly with ExcludeAssets="all". These tests never collect coverage, so this change only brings back the net40 Cecil build.
• Remove the old pin comment in Directory.Packages.props. The comment no longer applied because the version is already 18.11.2.

Verification

Ran locally on Windows:

• Before: net472 had 3 failures, the same as CI.
• After: net472 3/3 passed; net8.0, net9.0 and net10.0 5/5 passed each.
• The net472 output no longer contains CodeCoverage assemblies, and Mono.Cecil.dll is the net40 build again.

Summary by CodeRabbit

• Bug Fixes

  • Improved reliability of public API compatibility checks on .NET Framework.
  • Prevented code coverage components from interfering with API validation during test runs.

• Maintenance

  • Updated test dependency handling to preserve consistent public API verification without changing runtime behavior or exported APIs.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-22T17:55:58.722471Z	ae57b80	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Advanced

Run ID: c2618049-7a9c-4166-b074-b7dbfa02588a

📥 Commits

Reviewing files that changed from the base of the PR and between 00f74ab and ae57b80.

📒 Files selected for processing (2)

• Directory.Packages.props
• tests/TUnit.PublicAPI/TUnit.PublicAPI.csproj

💤 Files with no reviewable changes (1)

• Directory.Packages.props

Included review availability: Your plan provides up to 8 included reviews per hour; 4 remain after this review.

---

📝 Walkthrough

Walkthrough

The public API test project now excludes all CodeCoverage package assets. This prevents its transitive Mono.Cecil.dll from overriding the framework-specific assembly required by PublicApiGenerator. An obsolete package-version comment was also removed.

Changes

Public API build compatibility

Layer / File(s)	Summary
Exclude CodeCoverage assets tests/TUnit.PublicAPI/TUnit.PublicAPI.csproj, Directory.Packages.props	The test project adds Microsoft.Testing.Extensions.CodeCoverage with ExcludeAssets="all". The package version comment is removed without changing the version reference.

Priority: ➖ Normal

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix · Severity of issue fixed: Medium

Merge Risk: ⚪ Minimal · up to ae57b

No actionable merge-blocking risk remains in this test-project compatibility change.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: restoring Windows net472 PublicAPI tests.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0…
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{A rabbit checks the public API trail
CodeCoverage assets stay still and pale
Mono.Cecil keeps its proper place
Facades resolve in the test-case race
The snapshots hop onward without fail}

_{Comment @coderabbitai help to get the list of available commands.}

[greptile-apps]

Confidence Score: 5/5

The PR appears safe to merge, with the exclusion narrowly scoped to a test project that does not invoke coverage.

Summary

This PR restores the Windows net472 PublicAPI test path by excluding all assets from the transitively supplied CodeCoverage package in that test project, preventing its netstandard2.0 Mono.Cecil assembly from displacing the .NET Framework-compatible assembly. It also removes a stale central-version comment.

• Adds a project-local asset exclusion for Microsoft.Testing.Extensions.CodeCoverage.
• Retains the centrally managed CodeCoverage version for projects that actually collect coverage.
• Leaves the PublicAPI project’s other target frameworks and package versions unchanged.

_{Reviews (1) · Last reviewed commit: "fix(ci): restore net472 PublicAPI tests ..."}

[github-actions]

Review: fix(ci): restore net472 PublicAPI tests on Windows

Small, well-scoped fix. I traced the dependency chain (TUnit.PublicAPI → TUnit.Playwright → TUnit → Microsoft.Testing.Extensions.CodeCoverage) and confirmed the root cause described in the PR body: 18.11+ of the CodeCoverage package ships a netstandard2.0 Mono.Cecil.dll that overwrites the net40 build in the net472 output, which PublicApiGenerator needs to resolve .NET Framework facades. Adding ExcludeAssets="all" on a direct PackageReference is the standard MSBuild way to suppress a transitive package's assets, and I confirmed via tools/TUnit.Pipeline/Modules/RunPublicAPITestsModule.cs that --coverage is never passed for this project, so the change doesn't alter any currently-observed behavior. Removing the stale pin comment in Directory.Packages.props is correct cleanup since the version comment no longer matched the pinned version.

No correctness or architectural issues. One minor, non-blocking observation:

tests/TUnit.PublicAPI/TUnit.PublicAPI.csproj:27 — the new PackageReference with ExcludeAssets="all" applies to all four TFMs (net472;net8.0;net9.0;net10.0), but the Mono.Cecil conflict described in the comment is net472-specific (the netstandard2.0 build only clobbers the net40 Cecil assembly used on .NET Framework). The file already has a precedent for TFM-scoped items (ItemGroup Condition="'$(TargetFramework)' != 'net472'" at line 30), so scoping this new reference the same way, e.g. Condition="'$(TargetFramework)' == 'net472'", would keep the exclusion limited to the framework that actually needs it and avoid silently suppressing coverage assets on net8.0/net9.0/net10.0 if coverage collection is ever turned on for this project. Low priority since coverage isn't collected here today, but worth considering for precision.

Other automated reviewers (CodeRabbit, Greptile, Codex) found no issues either. Approving from a correctness standpoint.