-
Notifications
You must be signed in to change notification settings - Fork 6k
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
Conversation
@@ -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 | |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this 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. |
There was a problem hiding this comment.
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.
Co-authored-by: Noah Falk <noahfalk@users.noreply.github.com>
Summary
Change references to unsupported and out of date versions of .NET to currently supported versions.
Internal previews
Toggle expand/collapse