.NET: chore: promote shipped .NET APIs

[Vincent Biret (baywet)]

follow up to #7935
Right now the automation is failing because a setting is not enabled at the organization level, I've made a request:

• https://github.com/microsoft/github-operations/issues/1754

[Copilot]

Pull request overview

Promotes the released WaitTimeout API from unshipped to shipped baselines for every supported .NET target framework.

Changes:

• Adds WaitTimeout getter and setter to shipped API baselines.
• Clears those entries from unshipped baselines.

Reviewed changes

Copilot reviewed 10 out of 10 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
PublicAPI/netstandard2.0/PublicAPI.Unshipped.txt	Removes promoted entries.
PublicAPI/netstandard2.0/PublicAPI.Shipped.txt	Adds shipped entries.
PublicAPI/net9.0/PublicAPI.Unshipped.txt	Removes promoted entries.
PublicAPI/net9.0/PublicAPI.Shipped.txt	Adds shipped entries.
PublicAPI/net8.0/PublicAPI.Unshipped.txt	Removes promoted entries.
PublicAPI/net8.0/PublicAPI.Shipped.txt	Adds shipped entries.
PublicAPI/net472/PublicAPI.Unshipped.txt	Removes promoted entries.
PublicAPI/net472/PublicAPI.Shipped.txt	Adds shipped entries.
PublicAPI/net10.0/PublicAPI.Unshipped.txt	Removes promoted entries.
PublicAPI/net10.0/PublicAPI.Shipped.txt	Adds shipped entries.

---

💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

MAF Automated Review — Iteration 1

Result: No findings
Scope: full PR (1 commit(s)): 550be05bf511
Model: gpt-5.6-sol

Overview

This PR mechanically promotes the existing WaitTimeout accessors from unshipped to shipped API baselines across every declared target framework without changing runtime code. The signatures remain experimental, match the implementation, and are removed from every corresponding unshipped baseline; repository validation also enforces baseline completeness and rejects remaining unshipped APIs during publishing. No publishable Critical, High, or Medium issue was established.

Reviewed the supplied pull-request change set across correctness, security/reliability, architecture, and failure behavior.
No publishable findings remained after source verification for this scope.

[github-code-quality]

Code Coverage Overview

Languages: C#

C# / code-coverage/dotnet

The overall line coverage in commit 550be05 in the promote-shipped-apis... branch is 83%. Line coverage data for the main branch is not yet available.

Show a line coverage summary of the most covered files.

File	main	promote-shipped-apis... 550be05	+/-
/home/runner/wo...valConverter.cs	—	100%	—
/home/runner/wo...entsProvider.cs	—	99%	—
/home/runner/wo...nticAnalyzer.cs	—	94%	—
/home/runner/wo...tClientAgent.cs	—	91%	—
/home/runner/wo...putConverter.cs	—	90%	—
/home/runner/wo...kflowBuilder.cs	—	90%	—
/home/runner/wo...kflowSession.cs	—	87%	—
/home/runner/wo...SkillsSource.cs	—	86%	—
/home/runner/wo...onExtensions.cs	—	81%	—
/home/runner/wo...ctionVisitor.cs	—	70%	—

[Roger Barreto (rogerbarreto)]

Why do this feature requires PR creation access?

Can we setup in such a way it doesn't and actually provide a report of what changes are needed as a message or artifact in the end of the check?

[Vincent Biret (baywet)]

Why do this feature requires PR creation access?

Can we setup in such a way it doesn't and actually provide a report of what changes are needed as a message or artifact in the end of the check?

I want to make sure we're talking about the same thing here: the coverage report integration with GitHub only requires the code quality permission, and it's working fine for now as far as I can tell.

The public API export promotion needs to create a PR whenever it promotes unshipped APIs to shipped APIs (moves things from one file to another). Those are PRs like this one, except it shouldn't have been created by me, but automatically. Those PRs can be created a couple of different ways:

• Using one users PATs, generally not recommended for security reasons if there are alternatives
• Using the GITHUB_TOKEN with the pull request write permission, a valid option, but our security teams chose to disable that.
• Using an app registration, I'll get started on that so it works automatically.

This what one of those automated PRs looks like with an app registration BinkyLabs/openapi-overlays-dotnet#329 (of course, the app would be different for us)

Let me know if you have any additional comments or questions.