Improve endpoint metadata debugging by overriding ToString
See original GitHub issueBackground and Motivation
It is useful to understand what behavior endpoint metadata is adding to an endpoint. A human-readable summary of metadata would make this much easier. It can be viewed when debugging, and in logs when metadata is logged.
https://github.com/dotnet/aspnetcore/issues/34604 is another potential use of human-readable endpoint metadata.
Proposed API
I propose overriding ToString on metadata types. See changes in https://github.com/dotnet/aspnetcore/pull/35231 and https://github.com/dotnet/aspnetcore/pull/39753 as examples.
override Microsoft.AspNetCore.Routing.DataTokensMetadata.ToString() -> string!
override Microsoft.AspNetCore.Routing.EndpointNameMetadata.ToString() -> string!
override Microsoft.AspNetCore.Routing.HostAttribute.ToString() -> string!
override Microsoft.AspNetCore.Routing.HttpMethodMetadata.ToString() -> string!
override Microsoft.AspNetCore.Routing.RouteNameMetadata.ToString() -> string!
override Microsoft.AspNetCore.Routing.SuppressLinkGenerationMetadata.ToString() -> string!
override Microsoft.AspNetCore.Routing.SuppressMatchingMetadata.ToString() -> string!
Alternative Designs
An alternative approach is to add an interface to get display information:
public interface IEndpointDebugText
{
string DebugText { get; }
}
I don’t think this adds anything. We already have ToString that is pretty much for this situation.
DebuggerDisplayAttribute
is not appropriate because there are situations where it is useful to get the debug value at runtime. e.g. logging. It is only useful if we provide debug text using something other than ToString.
Risks
Someone uses endpoint metadata ToString to drive application behavior, and we change the ToString value. I don’t think this is a valid concern. Someone could depend on text in exception messages and logging, and those change from time to time.
Issue Analytics
- State:
- Created 2 years ago
- Reactions:1
- Comments:21 (21 by maintainers)
Top GitHub Comments
API review: API approved. We’re happy to consider using ToString instead of alternate ways such as interface implementation. We do not guarantee that the returned string would be consistent across releases. We should try and make the strings appear similar without dictating a serialization format. Legibility is the primary motive here.