Skip to content

Update unsupported verssions of .NET in diagnostics documentation #39651

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 2 commits into from

Conversation

tommcdon
Copy link
Member

@tommcdon tommcdon commented Feb 23, 2024

Summary

Change references to unsupported and out of date versions of .NET to currently supported versions.


Internal previews

Toggle expand/collapse
📄 File 🔗 Preview link
docs/core/diagnostics/available-counters.md docs/core/diagnostics/available-counters
docs/core/diagnostics/compare-metric-apis.md docs/core/diagnostics/compare-metric-apis
docs/core/diagnostics/debug-deadlock.md docs/core/diagnostics/debug-deadlock
docs/core/diagnostics/debug-highcpu.md docs/core/diagnostics/debug-highcpu
docs/core/diagnostics/debug-linux-dumps.md docs/core/diagnostics/debug-linux-dumps
docs/core/diagnostics/debug-memory-leak.md docs/core/diagnostics/debug-memory-leak
docs/core/diagnostics/debug-threadpool-starvation.md docs/core/diagnostics/debug-threadpool-starvation
docs/core/diagnostics/debug-windows-dumps.md docs/core/diagnostics/debug-windows-dumps
docs/core/diagnostics/diagnostic-port.md docs/core/diagnostics/diagnostic-port
docs/core/diagnostics/diagnostics-in-containers.md docs/core/diagnostics/diagnostics-in-containers
docs/core/diagnostics/diagnosticsource-diagnosticlistener.md docs/core/diagnostics/diagnosticsource-diagnosticlistener
docs/core/diagnostics/dotnet-gcdump.md docs/core/diagnostics/dotnet-gcdump
docs/core/diagnostics/event-counter-perf.md docs/core/diagnostics/event-counter-perf
docs/core/diagnostics/eventsource-activity-ids.md docs/core/diagnostics/eventsource-activity-ids
docs/core/diagnostics/eventsource-collect-and-view-traces.md docs/core/diagnostics/eventsource-collect-and-view-traces
docs/core/diagnostics/eventsource-getting-started.md docs/core/diagnostics/eventsource-getting-started
docs/core/diagnostics/eventsource-instrumentation.md docs/core/diagnostics/eventsource-instrumentation
docs/core/diagnostics/eventsource.md docs/core/diagnostics/eventsource
docs/core/diagnostics/metrics-collection.md docs/core/diagnostics/metrics-collection
docs/core/diagnostics/metrics-instrumentation.md docs/core/diagnostics/metrics-instrumentation
docs/core/diagnostics/microsoft-diagnostics-netcore-client.md docs/core/diagnostics/microsoft-diagnostics-netcore-client
docs/core/unmanaged-api/debugging/createdebugginginterfacefromversion2-function.md docs/core/unmanaged-api/debugging/createdebugginginterfacefromversion2-function
docs/core/unmanaged-api/profiling/icorprofilerinfo11-getenvironmentvariable-method.md docs/core/unmanaged-api/profiling/icorprofilerinfo11-getenvironmentvariable-method
docs/core/unmanaged-api/profiling/icorprofilerinfo11-interface.md docs/core/unmanaged-api/profiling/icorprofilerinfo11-interface
docs/core/unmanaged-api/profiling/icorprofilerinfo11-setenvironmentvariable-method.md docs/core/unmanaged-api/profiling/icorprofilerinfo11-setenvironmentvariable-method

@tommcdon tommcdon requested a review from a team as a code owner February 23, 2024 17:30
@dotnet-bot dotnet-bot added this to the February 2024 milestone Feb 23, 2024
@tommcdon tommcdon requested review from noahfalk and hoyosjs February 23, 2024 17:31
@@ -16,27 +16,27 @@ The following counters are published as part of .NET runtime (CoreCLR) and are m

| Counter | Description | First available in |
|--|--|--|
| :::no-loc text="% Time in GC since last GC"::: (`time-in-gc`) | The percent of time in GC since the last GC | .NET Core 3.1 |
Copy link
Member

Choose a reason for hiding this comment

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

This feels more about when were they introduced rather than supported. Is this needed?

Copy link
Member Author

Choose a reason for hiding this comment

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

Should we remove the column then? It doesn't feel useful to know when a particular counter was introduced if it predates all available versions of .NET.

Copy link
Member

@noahfalk noahfalk Feb 23, 2024

Choose a reason for hiding this comment

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

I think leaving the column as it was still might help clarify that these counters are not available on .NET Framework. It also preserves the structure of the table because some counters were introduced recently enough (.NET 7 for example) that we have supported versions that both do and do not have the counter. It would feel a little odd if some tables have the extra column but others don't depending on whether a counter was added in the last 3 years.

@@ -164,11 +164,11 @@ dotnet-gcdump report [-h|--help] [-p|--process-id <pid>] [-t|--report-type <Heap

- There is no type information in the gcdump.

Prior to .NET Core 3.1, there was an issue where a type cache was not cleared between gcdumps when they were invoked with EventPipe. This resulted in the events needed for determining type information not being sent for the second and subsequent gcdumps. This was fixed in .NET Core 3.1-preview2.
Prior to .NET 6, there was an issue where a type cache was not cleared between gcdumps when they were invoked with EventPipe. This resulted in the events needed for determining type information not being sent for the second and subsequent gcdumps. This was fixed in .NET 6-preview2.
Copy link
Member

Choose a reason for hiding this comment

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

This is now wrong. This note doesn't feel relevant anymore.

Copy link
Member

Choose a reason for hiding this comment

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

And same for the one below

Copy link
Member Author

Choose a reason for hiding this comment

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

I'll delete the text since it is no longer needed

@@ -297,7 +297,7 @@ Gets an `IDictionary` of key-value pair strings representing optional arguments

### Remarks

This class is immutable, because EventPipe does not allow a provider's configuration to be modified during an EventPipe session as of .NET Core 3.1.
This class is immutable, because EventPipe does not allow a provider's configuration to be modified during an EventPipe session as of .NET 6.
Copy link
Member

Choose a reason for hiding this comment

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

I think we can delete these Remarks. Its implied that the type is immutable because there are no property setters or other APIs that support mutation. In the future if we made EventPipe configuration mutable we still probably wouldn't do it by making this specific type mutable. I don't think there is any tight connection between the mutability of this type and overall capabilities of EventPipe.

@@ -72,4 +72,4 @@ HRESULT CreateDebuggingInterfaceFromVersion2 (

**Library:** dbgshim.dll, libdbgshim.so, libdbgshim.dylib

**.NET Versions:** Available since .NET Core 3.1
**.NET Versions:** Available since .NET 6
Copy link
Member

Choose a reason for hiding this comment

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

For API documentation it seems nice to leave this as .NET Core 3.1 so people know the real version where the API was added. I'm pretty sure we do the same thing for other APIs across .NET and Windows even though the versions may be old and out-of-support.

Ditto for the 3 profiler APIs below in the PR.

@BillWagner BillWagner modified the milestones: February 2024, April 2024 Mar 7, 2024
Copy link
Contributor

@gewarren gewarren left a comment

Choose a reason for hiding this comment

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

@tommcdon Are you still planning to work on this? Otherwise I can make the suggested changes.


- COM and static types aren't in the GC dump.

Prior to .NET Core 3.1, there was an issue where static and COM types weren't sent when the GC dump was invoked via EventPipe. This has been fixed in .NET Core 3.1.
Prior to .NET 6, there was an issue where static and COM types weren't sent when the GC dump was invoked via EventPipe. This has been fixed in .NET 6.
Copy link
Contributor

Choose a reason for hiding this comment

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

Should be deleted as per previous comment.

@BillWagner BillWagner modified the milestones: April 2024, May 2024 May 2, 2024
@BillWagner BillWagner modified the milestones: May 2024, June 2024 Jun 3, 2024
@BillWagner BillWagner modified the milestones: June 2024, July 2024 Jul 1, 2024
@BillWagner
Copy link
Member

@tommcdon @gewarren Is this still relevant? Should we close without merging?

Co-authored-by: Noah Falk <noahfalk@users.noreply.github.com>
@BillWagner BillWagner modified the milestones: July 2024, August 2024 Aug 13, 2024
@gewarren gewarren closed this Sep 5, 2024
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.

6 participants