Skip to content

[release/10.0.1xx] Reduce noise from CA1873 (#51818)#51839

Merged
jeffhandley merged 1 commit intodotnet:release/10.0.1xxfrom
stephentoub:backport51818
Dec 4, 2025
Merged

[release/10.0.1xx] Reduce noise from CA1873 (#51818)#51839
jeffhandley merged 1 commit intodotnet:release/10.0.1xxfrom
stephentoub:backport51818

Conversation

@stephentoub
Copy link
Member

@stephentoub stephentoub commented Nov 21, 2025

Backport of #51818 to release/10.0.1xx

Addresses feedback on the noise level for CA1873: Avoid potentially expensive logging (code analysis).

Customer Issue

Customers that enabled this analyzer with adoption of .NET 10 reported the volume of diagnostics reported was greater than expected and that there were varying degrees of severity yet all diagnostics were reported equally. Finding signal within the noise was a challenge, leading to the reaction of disabling the analyzer despite it offering many suggestions that would be valuable.

The analyzer did not provide any ability to configure the diagnostics to focus on expensive logging within hot paths vs. expensive logging in code paths where the expense is acceptable or even purposeful. The only workarounds would be to either disable the analyzer or to go through all diagnostics and suppress at call sites where the expensive logging is intended.

Description

The analyzer is updated in a couple ways:

  1. Because property accesses are common in logging calls and property accesses are supposed to be cheap, we avoid raising diagnostics for property accesses.
  2. As GetType/GetHashCode/GetTimestamp are used reasonably-frequently in logging calls; special-case them to avoid diagnostics for them even though they could be considered expensive.
  3. Add configurability of the Log levels that the analyzer reports diagnostics for, defaulting to only kick in for Information and below. The main reason this rule exists is to eliminate cost on hot paths. Generally such hot paths aren't raising warning/error/critical diagnostics, such that the more rare warning/errors don't need as much attention to overheads.

Was this a regression?

  • Yes
  • No

Testing

A high-volume diagnostic code base was used to validate the developer experience improves as desired with these changes. The code base now reports diagnostics that are clearly actionable and valuable while avoiding diagnostics for call sites and log levels where the expensive logging is acceptable.

Risk

Low. This analyzer is new in .NET 10, it is disabled by default, and now we are reducing the volume of diagnostics reported while also providing configuration to further reduce it.

Several improvements to the analyzer:

- Property accesses are common in logging calls, and property accesses are supposed to be cheap. Avoid raising diagnostics for property accesses.
- GetType/GetHashCode/GetTimestamp are used reasonably-frequently in logging calls; special-case them to avoid diagnostics for them.
- The main reason this rule exists is to eliminate cost on hot paths. Generally such hot paths aren't raising warning/error/critical diagnostics, such that the more rare warning/errors don't need as much attention to overheads. As such, I've changed the checks to only kick in by default for information and below, with a configuration switch that can be used to override to what levels it applies.
@stephentoub stephentoub requested a review from a team as a code owner November 21, 2025 01:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants