[Automated] Update dotnet CLI Options

[thomhurst]

Summary

This PR contains automatically generated updates to dotnet CLI options classes.

The generator scraped the latest CLI help output from the installed tool.

Changes

• Updated options classes to reflect latest CLI documentation
• Added new commands if any were detected
• Updated option types and descriptions

Assembly-wide public API impact

Affected API families: Assembly/common, DotNet.

• Added APIs: 189
• Removed or changed APIs: 209
• Members with matching names but changed signatures: 125

Breaking changes are present. Consumers may need to update method arguments, option property types or nullability, enum members, and references to removed APIs.

Representative removed or changed members:

• ModularPipelines.DotNet.Options.DotNetBuildOptions.Debug.get -> bool?
• ModularPipelines.DotNet.Options.DotNetBuildOptions.Debug.set -> void
• ModularPipelines.DotNet.Options.DotNetBuildOptions.Nologo.get -> bool?
• ModularPipelines.DotNet.Options.DotNetBuildOptions.Nologo.set -> void
• ModularPipelines.DotNet.Options.DotNetCleanOptions.Nologo.get -> bool?

Representative added members:

• ModularPipelines.DotNet.Options.DotNetNewDetailsOptions.Deconstruct(out string! PackageIdentifier) -> void
• ModularPipelines.DotNet.Options.DotNetNewDetailsOptions.DotNetNewDetailsOptions(string! PackageIdentifier) -> void
• ModularPipelines.DotNet.Options.DotNetNewDetailsOptions.PackageIdentifier.get -> string!
• ModularPipelines.DotNet.Options.DotNetNewDetailsOptions.PackageIdentifier.init -> void
• ModularPipelines.DotNet.Options.DotNetNewInstallOptions.Deconstruct(out System.Collections.Generic.IEnumerable<string!>! Package) -> void

Command coverage

Command coverage report:

• dotnet (10.0.400): 97 commands, tree 5a6ae5c35827884fff645cc37ecfe24e941dde2425778fae8feb055e1a0e1155
  • Baseline comparison: 97 commands at 10.0.400 -> 97 commands at 10.0.400

Verification

• Solution builds successfully

---

🤖 Generated with ModularPipelines.OptionsGenerator

[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-06T08:41:53.203239Z	9d96420	New commits

ℹ️ 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]

Important

Review skipped

Review was skipped as selected files did not have any reviewable changes.

💤 Files selected but had no reviewable changes (2)

• src/ModularPipelines.DotNet/PublicAPI.Shipped.txt
• src/ModularPipelines.DotNet/PublicAPI.Unshipped.txt

⛔ Files ignored due to path filters (1)

• src/ModularPipelines.DotNet/Generated/DotNet.Generation.json is excluded by !**/generated/**

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Team

Run ID: 415dba6b-b1e2-4a59-bc02-e50d853e0f8f

📥 Commits

Reviewing files that changed from the base of the PR and between 4be8181 and 9d96420.

⛔ Files ignored due to path filters (1)

• src/ModularPipelines.DotNet/Generated/DotNet.Generation.json is excluded by !**/generated/**

📒 Files selected for processing (2)

• src/ModularPipelines.DotNet/PublicAPI.Shipped.txt
• src/ModularPipelines.DotNet/PublicAPI.Unshipped.txt

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

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

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

[github-actions]

Code Review

This PR is the automated dotnet CLI options regeneration bot run — it touches only src/ModularPipelines.DotNet/Generated/DotNet.Generation.json, PublicAPI.Shipped.txt, and PublicAPI.Unshipped.txt. No hand-authored .Generated.cs option/service classes are modified, consistent with this repo's rule that generated options must never be hand-tweaked and should flow through the scraper/generator.

I spot-checked a broad sample of the ~1350 added / ~1200 removed PublicAPI entries (e.g. DotNetBuildOptions.Debug/.Nologo, DotNetRunOptions.ApplicationArguments, DotNetNuGetAddClientCertOptions.FindBy/FindValue/StoreLocation/StoreName, DotNetNuGetSignOptions.HashAlgorithm, IDotNetNuGet.SignAsync, and the TestOutcome.Inconclusive/InProgress reordering) against the actual .Generated.cs sources on both main and the PR branch. In every case checked, the "new" state being written into the PublicAPI tracking files already matches the current generated code — this PR is syncing a pre-existing drift between main's tracking files and the already-current generated sources, not introducing a new API change itself.

Additional checks: no duplicate entries in the new Shipped.txt/Unshipped.txt (sort | uniq -d clean), the two SHA256 hashes in the new DotNet.Generation.json are well-formed, and toolVersion: 10.0.400 matches global.json's SDK version.

No actionable issues found.

[github-actions]

Review

This is a fully automated, mechanical PR — it touches only src/ModularPipelines.DotNet/PublicAPI.Shipped.txt, PublicAPI.Unshipped.txt, and a new Generated/DotNet.Generation.json. No .cs files change at all. I traced a sample of the individual add/remove/*REMOVED* triads (e.g. DotNetNewDetailsOptions.PackageIdentifier, DotNetNuGetAddClientCertOptions.FindBy) against the actual (unchanged) generated source and confirmed each entry correctly reflects the current shape of the corresponding *.Generated.cs file — I found no incorrect or fabricated API entries.

Two things worth flagging:

1. The PR description overstates what changed here. It reads as if the generator freshly scraped dotnet CLI help and produced ~200 new/changed APIs, but I verified DotNetNewDetailsOptions.Generated.cs (and others referenced in the diff) are byte-identical between main and this PR's head — none of the .cs option classes are touched. That means the source already had this shape before this PR, and PublicAPI.*.txt had silently drifted out of sync with it (an earlier change presumably landed without updating the tracking files). This PR is a catch-up of the tracking files, not a reflection of a new CLI scrape. Worth calling out explicitly in the PR body/generator, since as written it's misleading about provenance, and the drift itself (source changing while PublicAPI.Shipped/Unshipped.txt didn't) suggests the analyzer gate that's supposed to catch this didn't fire for whatever change introduced it — worth double-checking that gate is wired up correctly so this doesn't require periodic bulk catch-up PRs going forward.

2. PublicAPI.Shipped.txt has a lot of pure reordering noise with no actual API change. E.g. TestOutcome.Inconclusive/InProgress simply swap positions (lines 21-22) with identical content on both sides — I confirmed this directly. This kind of unstable sort inflates an already-large diff (993 additions / 1155 deletions) with churn unrelated to any real change, making it much harder for a human to spot a genuinely wrong entry (wrong type, wrong nullability, etc.) among the noise. Recommend stabilizing the emit order in the options generator/scraper (e.g. always sort by the same key, matching how Roslyn's PublicAPI.Shipped.txt convention expects entries) so future automated runs produce diffs proportional to the actual API surface change, not to incidental ordering differences.

Neither point is a functional bug in this specific diff, but both affect how trustworthy/reviewable these automated PRs are over time, so I'd like to see them addressed (at least the reordering, since it directly hides real changes in every future auto-PR of this kind).

[github-actions]

Review

This is the automated dotnet CLI options regeneration bot run. It touches only src/ModularPipelines.DotNet/Generated/DotNet.Generation.json (new file), PublicAPI.Shipped.txt, and PublicAPI.Unshipped.txt. I independently diffed every *.Generated.cs file under src/ModularPipelines.DotNet/Generated between main and this PR's head and confirmed they are byte-identical — no hand-authored or generated option/service class changes at all, consistent with this repo's rule that generated options must never be hand-tweaked.

I spot-checked a sample of the added/removed PublicAPI entries against the actual (unchanged) source:

• DotNetNewDetailsOptions: the removed entries (parameterless ctor, mutable PackageIdentifier get/set) and added entries (positional ctor, Deconstruct, init-only PackageIdentifier) match the current record definition in DotNetNewDetailsOptions.Generated.cs exactly.
• DotNetNuGetAddClientCertOptions: FindBy, FindValue, StoreLocation, StoreName all exist as documented in the source.
• No duplicate entries in either Shipped.txt or Unshipped.txt (sort | uniq -d clean on both).
• The new DotNet.Generation.json hashes and toolVersion: 10.0.400 are well-formed and match global.json.

Following up on the prior automated review's BLOCKING finding (reordering churn)

The earlier review flagged the TestOutcome.Inconclusive/InProgress swap (and similar reordering) as noise that inflates the diff and asked for the generator to stabilize emit order. I read tools/ModularPipelines.OptionsGenerator/scripts/Merge-PublicApiBaselineSnapshot.ps1, which is the script that actually writes these two files: it already dedupes into a HashSet<string> and sorts with [Array]::Sort using StringComparer.Ordinal consistently for both Shipped.txt and Unshipped.txt. That's deterministic and matches Roslyn's own PublicAPI.*.txt ordinal convention (ordinally, P sorts before c, so InProgress correctly sorts before Inconclusive, which is what this PR now produces).

That means the reordering in this diff is a one-time correction of entries in main's baseline that predate consistent ordinal sorting (likely from an earlier manual edit or an older generator version), not evidence of an unstable/non-deterministic generator today. Given the merge script's sort is already stable, future regeneration runs should not reintroduce this kind of churn. I don't think further generator changes are needed here — happy to be corrected if a maintainer has seen non-deterministic ordering recur across multiple runs of this exact script.

The PR description's boilerplate text ("scraped the latest CLI help output... added new commands if any were detected") is still generic auto-generated wording that doesn't reflect that this particular run only reconciled the tracking files with already-shipped source — same observation the earlier review made. This is cosmetic (PR body text, not code) and not something worth blocking on.

No actionable code issues found in the current head.

[github-actions]

Review

I verified the generator-provenance freshness check for this automated snapshot update, since that's the only substantive risk in an auto-generated options PR like this.

Blocking: generated snapshot is stale against its own base branch

src/ModularPipelines.DotNet/Generated/DotNet.Generation.json records generatorSourceSha256: 0859f0fd6792cfb9030fc7298189d85032a5a39ddc7c4bfad3e57603f682d188.

I recomputed Get-GeneratedOptionsSourceFingerprint (scripts/GeneratedOptionsProvenance.ps1) by hashing the git object IDs of the same source list at this PR's base commit (f65c8825, which is also current main HEAD) and got fbab3128f0ed5635d903702f6a8b132d9f14d185357f8429068a28f853bc4032 — a mismatch.

That means .github/workflows/dotnet.yml's "Reject stale generated snapshots" step will fail: Assert-GeneratedOptionsFreshness.ps1 compares the stored generatorSourceSha256 against a fresh fingerprint of origin/$BASE_REF and throws "Generated snapshots for 'dotnet' are stale..." when they differ (scripts/Assert-GeneratedOptionsFreshness.ps1:53-55). This will block merge even though the dotnet options content itself looks correctly generated.

Suggested fix: re-run the "Generate CLI Options" workflow for dotnet from current main so Write-GeneratedOptionsProvenance.ps1 stamps a fingerprint that matches origin/main at merge time, rather than editing the JSON by hand (per repo convention, hand-editing generated snapshot files should be avoided — regenerate instead).

No other issues found; the generated options diff itself (added/removed/changed members) is consistent with the described upstream dotnet CLI changes.

[github-actions]

Review: PR #4648 — chore: Update dotnet CLI options

This is a fully automated, bot-generated regeneration of dotnet CLI option metadata. The diff touches exactly 3 files:

• src/ModularPipelines.DotNet/Generated/DotNet.Generation.json — updated scraped dotnet CLI command tree + hashes
• src/ModularPipelines.DotNet/PublicAPI.Shipped.txt / PublicAPI.Unshipped.txt — updated public API tracking

No hand-written or generated .cs source files are changed — confirmed via a diff of src/ModularPipelines.DotNet/Options and Services between main and the PR head (byte-identical).

Verification performed

• Cross-checked ~25 of the more notable additions/removals (type changes, bool→string fixes like CertificateFingerprint, HashAlgorithm, TimestampHashAlgorithm, PackagePaths renames, the bool+...Value pairs on DotNetNuGetAddClientCertOptions, DotNetNewOptions.TemplateArgs, DotNetBuildOptions.Debug/Nologo removals, etc.) against the actual .Generated.cs files — every sampled entry matches the real property signatures.
• Checked for symbols appearing in both Shipped.txt and Unshipped.txt simultaneously (would be a PublicAPI-analyzer error) — none found.
• Checked for duplicate lines within each tracking file — none found.

Conclusion

Per this repo's CLAUDE.md, this kind of breaking, tool-driven regeneration is the explicitly intended workflow ("Current tool output is the sole source of truth for generated options, even when regeneration causes breaking API changes"). The breaking removals (e.g. Debug, Nologo on DotNetBuildOptions) are expected consequences of the CLI scrape reflecting the current dotnet tool output, not bugs introduced by this PR.

No actionable findings.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e681342e2d

ℹ️ 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".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[github-actions]

Review

This is the automated dotnet CLI options regeneration bot run. The diff touches exactly three files: src/ModularPipelines.DotNet/Generated/DotNet.Generation.json (new provenance manifest), PublicAPI.Shipped.txt, and PublicAPI.Unshipped.txt. No hand-authored or .Generated.cs option/service classes are modified — confirmed the sampled generated sources (e.g. DotNetNuGetAddClientCertOptions.Generated.cs) are byte-identical between main and this PR's head, consistent with this repo's rule that generated options must never be hand-tweaked and should flow through the scraper/generator.

Verification performed:

• Provenance freshness: an earlier automated review on a prior push of this same branch flagged the generator-source fingerprint as stale against main. I independently recomputed Get-GeneratedOptionsSourceFingerprint (hashing the git object IDs of the 13 generator-input paths from scripts/GeneratedOptionsProvenance.ps1) at the current base commit (f4bfc2e7, which is current main HEAD) and got 724e6e24b67faf1e28bb6a5b10892f1481716a0ca3c7a36e4d874055980a701d — this matches the generatorSourceSha256 stored in this PR's DotNet.Generation.json exactly. The staleness issue raised on an earlier revision of this branch has been resolved at the current head; the "Reject stale generated snapshots" CI gate should pass.
• toolVersion (10.0.400) and commandTreeSha256 in DotNet.Generation.json match global.json's SDK version and the existing (unchanged) DotNet.CommandCoverage.json respectively.
• No duplicate lines in either PublicAPI.Shipped.txt or PublicAPI.Unshipped.txt (sort | uniq -d clean on both).
• Spot-checked several of the larger changes against the real generated source: the FindBy/FindValue/PackageSource/StoreLocation/StoreName properties on DotNetNuGetAddClientCertOptions/DotNetNuGetUpdateClientCertOptions consolidate from a bool-flag + separate ...Value string pair into a single string? property — this matches DotNetNuGetAddClientCertOptions.Generated.cs (public string? FindBy { get; set; }) exactly, and is a genuine simplification of the previous split-property representation.
• The TestOutcome.Inconclusive/InProgress (and similar) reordering in PublicAPI.Shipped.txt is a one-time ordinal-sort correction, not evidence of non-deterministic output — Merge-PublicApiBaselineSnapshot.ps1 already sorts both tracking files with StringComparer.Ordinal consistently, so future regenerations shouldn't reintroduce this kind of churn.

Per this repo's CLAUDE.md, breaking, tool-driven regeneration is the explicitly intended workflow here ("current tool output is the sole source of truth for generated options, even when regeneration causes breaking API changes"), and the removed/changed members (e.g. DotNetBuildOptions.Debug/Nologo → NoLogo) are expected consequences of that, not bugs introduced by this PR.

No actionable issues found in the current head.

[github-actions]

Review

This is the automated dotnet CLI options regeneration bot run. The diff touches exactly three files: src/ModularPipelines.DotNet/Generated/DotNet.Generation.json (new provenance manifest), PublicAPI.Shipped.txt, and PublicAPI.Unshipped.txt. No hand-authored or .Generated.cs option/service classes are modified — a full diff -rq of src/ModularPipelines.DotNet/Options and src/ModularPipelines.DotNet/Services between main and this PR's head (ff96b27) is empty, consistent with this repo's rule that generated options must never be hand-tweaked and should flow through the scraper/generator.

Verification performed on the current head:

• Provenance freshness: independently recomputed Get-GeneratedOptionsSourceFingerprint (SHA-256 over the git object IDs of the 13 generator-input paths from scripts/GeneratedOptionsProvenance.ps1) at current main HEAD (863a9502) using plain git rev-parse + sha256sum, and got 3c4a4b7d77c9c486eefb33c6d9f0e900bd1623eade9ce8de1537082c1d5cebeb — this matches the generatorSourceSha256 in this PR's DotNet.Generation.json exactly. Not stale.
• commandTreeSha256 in the new manifest (5a6ae5c3...) matches DotNet.CommandCoverage.json on main, and toolVersion: 10.0.400 matches global.json's SDK version.
• No duplicate lines in either PublicAPI.Shipped.txt or PublicAPI.Unshipped.txt (sort | uniq -d clean on both).
• Spot-checked the two most structurally significant change categories against the real (unchanged) generated source on the PR head:
  • DotNetNewDetailsOptions and other 'positional operand' options: the diff's removed mutable get/set + parameterless constructor and added positional constructor + Deconstruct + init-only property match DotNetNewDetailsOptions.Generated.cs's public record DotNetNewDetailsOptions([property: CliArgument(0, ..., Required = true)] string PackageIdentifier) exactly.
  • DotNetNuGetAddClientCertOptions.FindBy/StoreLocation/StoreName: the diff's consolidation from a bool? flag + separate ...Value string pair into a single string? property matches the source (public string? FindBy { get; set; }, etc.) exactly.
  • The removed IDotNet.FormatAsync convenience method has no replacement anywhere in Services/ on either branch (confirmed via grep) — this is the tracking file catching up to source that was already this shape, not a new regression from this run.

Per this repo's CLAUDE.md, breaking, tool-driven regeneration is the explicitly intended workflow ('current tool output is the sole source of truth for generated options, even when regeneration causes breaking API changes'), and this run's removed/changed members (Debug, Nologo→NoLogo, the flag/value merges, etc.) are consistent with that policy.

No actionable issues found in the current head.

[github-actions]

Review: PR #4648 — automated dotnet CLI options regeneration

This is a fully automated, bot-generated regeneration of dotnet CLI option metadata. The diff touches exactly 3 files:

• src/ModularPipelines.DotNet/Generated/DotNet.Generation.json (new provenance manifest)
• src/ModularPipelines.DotNet/PublicAPI.Shipped.txt
• src/ModularPipelines.DotNet/PublicAPI.Unshipped.txt

No hand-authored or .Generated.cs option/service classes are touched, consistent with this repo's rule that generated options must flow through the scraper/generator rather than being hand-tweaked.

Previously flagged blocking issue is now resolved

An earlier review on this PR (2026-09-06 01:32 UTC) flagged that generatorSourceSha256 in DotNet.Generation.json was stale against main, which would fail the "Reject stale generated snapshots" CI step (Assert-GeneratedOptionsFreshness.ps1). I independently recomputed Get-GeneratedOptionsSourceFingerprint by hashing the git object IDs of the same source list (scripts/GeneratedOptionsProvenance.ps1) at current main (8abd6753, this PR's base) and got 773b4f943140dab43ee649323893d06346286caa0635dcf177d0bfb536a63497 — this now matches the value stamped in the PR head commit (1fa25a8). The snapshot has been re-run since that comment and is fresh; the freshness gate will pass.

I also confirmed DotNet.CommandCoverage.json (unchanged, already on main) has a matching commandTreeSha256 and toolVersion to the new DotNet.Generation.json, so the coverage-manifest consistency check will pass too.

Spot-checked content correctness

Sampled a handful of the larger PublicAPI churn clusters and they all read as genuine generator/data-quality fixes reflecting the real dotnet 10.0.400 CLI surface, not regressions:

• DotNetNuGetAddClientCertOptions/UpdateClientCertOptions: options like FindBy, FindValue, PackageSource, StoreLocation, StoreName previously existed twice (a spurious bool? flag property plus a separate ...Value string? property). They're now collapsed into a single string? value property, which matches how these CLI options actually behave (each takes one value, none are bare flags).
• DotNetNuGetAddSourceOptions.Packagesourcepath (bad casing, optional) → PackageSourcePath (correct casing) modeled as a required primary-constructor parameter with Deconstruct, matching that PACKAGE_SOURCE_PATH is a required positional argument for dotnet nuget add source.
• DotNetBuildOptions/DotNetCleanOptions: duplicate Nologo/NoLogo casing collapsed to just NoLogo.
• DotNetNewOptions.TemplateArgs: string? → IEnumerable<string!>?, correctly modeling that template args are multiple values.
• New dotnet new create/details/install/list/search/uninstall and dotnet nuget config get/... option classes align with the command list in DotNet.CommandCoverage.json.

Breaking changes are expected and acceptable here per this repo's convention (current CLI output is the source of truth; no compatibility shims for generated options).

Verdict

No actionable issues remain. The one substantive risk for this kind of PR (a stale provenance stamp silently blocking merge) has been fixed and I verified the fix independently rather than just trusting the stamp.

[github-actions]

Review

This PR is a fully automated regeneration of the DotNet tool's options, touching only:

• src/ModularPipelines.DotNet/Generated/DotNet.Generation.json
• src/ModularPipelines.DotNet/PublicAPI.Shipped.txt
• src/ModularPipelines.DotNet/PublicAPI.Unshipped.txt

No hand-written .cs source was modified, consistent with CLAUDE.md's guidance that generated options must never be hand-tweaked — this looks like a clean scraper/generator regeneration output.

Verification performed:

• Both PublicAPI.Shipped.txt and PublicAPI.Unshipped.txt remain correctly ordinally sorted, with no duplicate entries.
• Every symbol removed from Shipped.txt has a corresponding *REMOVED* bookkeeping entry added to Unshipped.txt, matching the Roslyn PublicAPI analyzer convention.
• The bool? → string?/string! type corrections (e.g. FindBy, FindValue, PackageSource, StoreLocation, StoreName, Packagesourcepath→PackageSourcePath) align with CLI options that genuinely take string values, so these read as legitimate scraper fixes rather than regressions.
• CI's "Solution builds successfully" gate will already fail on any PublicAPI-analyzer mismatch, which corroborates the manual checks above.

No correctness, design, or architectural issues found. Nothing here warrants blocking.

[thomhurst]

Latest-options audit confirmed the baseline lifecycle problem is tracked in #4638 / #4644. The independent freshness-gate gap is now explicitly tracked in #4740. Current provenance matches main (773b4f943140dab43ee649323893d06346286caa0635dcf177d0bfb536a63497). Under the requested merge-latest workflow, these generator/workflow fixes remain follow-ups; no handwritten baseline or generated-options patch. Resolving review threads as tracked follow-ups, not as fixes in this generated snapshot.