chore: consolidate MongoDB TFMs and add net10.0 to MySql projects

[holytshirt]

Summary

• Extract BrighterMongoTargetFrameworks property (net472;$(BrighterCoreTargetFrameworks)) in src/Directory.Build.props so all MongoDB projects share a single TFM definition
• Replace repeated net472;$(BrighterCoreTargetFrameworks) in 5 MongoDB csproj files with $(BrighterMongoTargetFrameworks)
• Upgrade MySql, Inbox.MySql, Outbox.MySql, and Locking.MySql from BrighterNetNineEarlierTargetFrameworks (net8.0;net9.0) to BrighterCoreTargetFrameworks (net8.0;net9.0;net10.0)
• MySql.EntityFrameworkCore intentionally left on net8.0;net9.0 — Pomelo.EntityFrameworkCore.MySql does not yet have a net10.0 release

Test plan

• CI builds pass for all target frameworks (net8.0, net9.0, net10.0, net472)
• NuGet packages generate correctly for MongoDB and MySql projects
• No regressions in MongoDB and MySql integration tests

🤖 Generated with Claude Code

[claude]

PR Review: chore clean up TFM properties - see review details below

[claude]

PR Review — chore: clean up TFM properties and csproj redundancy

This is a solid infrastructure cleanup. The centralization of build properties will make future TFM bumps much less error-prone. A few things worth double-checking before merge.

---

Potential Issues

1. Paramore.Brighter.Locking.MsSql loses its NuGet <Description>

The diff removes <Description>A Locking Provider for Microsoft SQL Server</Description> along with the duplicate <Nullable> and the per-project <TreatWarningsAsErrors>. If that was the only <Description> element in the file, the published NuGet package will have a blank description. Please verify the file still has a description after the change, or add it back.

2. Paramore.Brighter.MySql targets changed from BrighterNetNineEarlierTargetFrameworks to BrighterTargetFrameworks

BrighterTargetFrameworks = netstandard2.0;net8.0;net9.0;net10.0. The previous value (net8.0;net9.0) never included netstandard2.0. Is MySqlConnector compatible with netstandard2.0? Adding netstandard2.0 here while the EF Core variant stays on BrighterNetNineEarlierTargetFrameworks also creates a TFM mismatch between the two MySQL packages. If the goal was just to add net10.0 support, the correct variable is probably BrighterCoreTargetFrameworks (net8.0;net9.0;net10.0), which is what the other MySQL packages (Inbox, Outbox, Locking) use.

3. Paramore.Brighter.MySql.EntityFrameworkCore not updated for net10.0

All other MySQL packages in this PR move to BrighterCoreTargetFrameworks (gaining net10.0), but MySql.EntityFrameworkCore is left on BrighterNetNineEarlierTargetFrameworks (net8.0;net9.0). If this is intentional (e.g., the EF Core provider for MySQL does not yet support net10.0), a comment would help explain why.

---

Minor Observations

4. Large XML doc warning suppression list — Adding 18 CS-doc warning codes to src/Directory.Build.props is a reasonable "unblock now, fix later" approach, but it is a lot to leave open-ended. Consider opening a follow-up issue to track writing the missing doc comments so this list can eventually be removed.

5. RestoreUseStaticGraphEvaluation removal — This flag was a restore-performance optimization for large solutions. Removing it is fine if it was causing issues, but the PR description does not mention why. A brief note in the PR body or a commit message would help future readers.

6. Missing newline at end of file — A few files still lack a trailing newline (Directory.Build.props, samples/TaskQueue/RMQRequestReply/Greetings/Greetings.csproj). Not a blocker, but worth a quick pass since these files are already being touched.

---

What is good

• Centralizing BrighterMongoTargetFrameworks eliminates the repeated net472;$(BrighterCoreTargetFrameworks) pattern across 6+ MongoDB project files.
• The inline comments explaining SignAssembly=false (Kafka, MQTT, Redis, RocketMQ, Hangfire, TickerQ) are helpful for future maintainers.
• Adding GenerateDocumentationFile=true to src/Directory.Build.props is the right direction for improving API discoverability.
• Using $(RabbitMQClientV6) in place of the hardcoded 6.8.1 version override is the correct pattern.
• The FluentMigrator migration projects that intentionally keep <Nullable>disable</Nullable> now have a comment explaining why.

Overall this is a good cleanup; the main ask is to double-check items 1–3 above before merging.

Review generated with Claude Code

[claude]

Code Review - PR 4062

This is a clean, focused maintenance PR.

DESCRIPTION MISMATCH: The PR description mentions several changes not present in the diff: renaming RabbitMQClientLegacy to RabbitMQClientV6, centralizing RabbitMQ.Client in Directory.Packages.props, enabling GenerateDocumentationFile, fixing NuGet CI generation, and updating samples to net9.0. The actual diff is narrower - only TFM consolidation for MongoDB and MySQL. Please update the description to match the actual scope.

FEEDBACK ON ACTUAL CHANGES:

1. BrighterMongoTargetFrameworks extraction - Good DRY improvement. Five MongoDB projects shared the same net472 + BrighterCoreTargetFrameworks combination. Centralizing this into a named property means future TFM changes only touch one place.

2. MySQL projects gaining net10.0 - Straightforward. Moving Inbox/Outbox/Locking from BrighterNetNineEarlierTargetFrameworks to BrighterCoreTargetFrameworks simply adds net10.0 support, consistent with the project direction.

3. Paramore.Brighter.MySql moving to BrighterTargetFrameworks - Worth discussion. This base package goes from net8.0;net9.0 all the way to netstandard2.0;net8.0;net9.0;net10.0, adding both netstandard2.0 and net10.0 in one step. MySqlConnector 2.5.0 does support netstandard2.0 so compilation should be fine. However there is a TFM asymmetry: the base targets netstandard2.0 but its consumers (Inbox.MySql, Outbox.MySql, Locking.MySql) only target net8.0+. netstandard2.0 consumers of Paramore.Brighter.MySql therefore cannot use the Inbox/Outbox/Locking packages. Is this intentional?

4. BrighterNetNineEarlierTargetFrameworks is now nearly orphaned - Only Paramore.Brighter.MySql.EntityFrameworkCore still uses this property. If that project is also expected to move to BrighterCoreTargetFrameworks eventually, consider either a follow-up PR or a comment in Directory.Build.props explaining why it is retained.

SUMMARY: The core refactoring is sound. Please (1) update the PR description to match the actual changes, and (2) confirm whether the netstandard2.0 addition to Paramore.Brighter.MySql is intentional.

[codescene-delta-analysis]

No application code in the PR — skipped Code Health checks.

See analysis details in CodeScene

Quality Gate Profile: Clean Code Collective
Install CodeScene MCP: safeguard and uplift AI-generated code. Catch issues early with our IDE extension and CLI tool.

[claude]

Code Review

This is a clean, low-risk maintenance PR. Here are my observations:

What works well

• The introduction of BrighterMongoTargetFrameworks correctly eliminates the repeated net472;$(BrighterCoreTargetFrameworks) pattern across 5 MongoDB .csproj files — good DRY improvement.
• The comment explaining why BrighterNetNineEarlierTargetFrameworks is retained (Pomelo.EntityFrameworkCore.MySql doesn't yet support net10.0) is helpful context for future maintainers.
• Paramore.Brighter.MySql.EntityFrameworkCore correctly stays on $(BrighterNetNineEarlierTargetFrameworks) — the dependency relationship is respected.
• MySqlConnector (2.5.0) targets netstandard2.0, so it will work on net10.0 via compatibility — no driver concern there.

Observations / Minor Points

1. PR title is slightly imprecise for MongoDB

The MongoDB projects already targeted net10.0 before this PR, because $(BrighterCoreTargetFrameworks) (net8.0;net9.0;net10.0) was already expanded inline as net472;$(BrighterCoreTargetFrameworks). The MongoDB changes in this PR are a pure refactoring (extracting a named variable), not adding a new TFM. The real net10.0 addition is for the MySql projects. The title could say something like:

chore: add net10.0 support to MySql projects; extract BrighterMongoTargetFrameworks variable

Not blocking — just a documentation nit.

2. BrighterNetNineEarlierTargetFrameworks name is now stale

With net10.0 existing, "NetNineEarlier" is confusing — it now means "pre-net10.0" but is named after net9. A future rename to something like BrighterMySqlEFCoreTargetFrameworks would be clearer and remove the implicit version coupling from the name. This is a pre-existing issue and doesn't need to be fixed in this PR.

3. CI: Snyk reports an ERROR

The Snyk check has an ERROR status. This may be a pre-existing issue unrelated to this PR, but worth verifying it isn't flagging a newly introduced dependency vulnerability.

Summary

No blocking issues. The change is correct and consistent. The two naming observations are minor and can be tracked separately.