Skip to content

Conversation

Copy link
Contributor

@tdykstra tdykstra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM aside from the typo noted.

@IEvangelist IEvangelist enabled auto-merge (squash) November 2, 2023 20:37
@IEvangelist IEvangelist merged commit 3a77d38 into dotnet:main Nov 2, 2023
<xref:System.Diagnostics.Metrics?displayProperty=nameWithType> API. For a listing of metrics based on the older [EventCounters](event-counters.md) API,
see [here](available-counters.md).

- [Meter: `Microsoft.AspNetCore.HeaderParsing`](#meter-microsoftaspnetcoreheaderparsing)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since Microsoft.AspNetCore.HeaderParsing is a part of dotnet/extensions, shouldn't we move description of this meter and its metrics to ".NET extensions metrics" article? @IEvangelist

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a fair question, but I'd argue "no". This package, while it ships out of dotnet/extensions is specific to ASP.NET Core and isn't workload agnostic, therefore it belongs with the other ASP.NET Core specific metrics (otherwise we're shipping our org chart so to speak). I suppose we should defer to @davidfowl and @joperezr, but I feel very strongly about this.

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.

.NET docs to include metrics emitted by extensions

5 participants