Improve endpoint metadata debugging by overriding ToString

[JamesNK]

Background 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.

#34604 is another potential use of human-readable endpoint metadata.

Proposed API

I propose overriding ToString on metadata types. See changes in #35231 and #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.

Thank you for submitting this for API review. This will be reviewed by @dotnet/aspnet-api-review at the next meeting of the ASP.NET Core API Review group. Please ensure you take a look at the API review process documentation and ensure that:

• The PR contains changes to the reference-assembly that describe the API change. Or, you have included a snippet of reference-assembly-style code that illustrates the API change.
• The PR describes the impact to users, both positive (useful new APIs) and negative (breaking changes).
• Someone is assigned to "champion" this change in the meeting, and they understand the impact and design of the change.

Thanks for contacting us.

We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[davidfowl]

Where does this show up to the user or when debugging?

[JamesNK]

endpoints.MapGet("/", c =>
{
    var endpoint = c.GetEndpoint();

    var metadata = endpoint.Metadata; // view all metadata
    var nameMetadata = metadata.GetMetadata<EndpointNameMetadata>(); // view one metadata
}

[pranavkm]

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.