sting.Format suggestion

[JustinMDotNet]

Hi,

My team uses the new ILogger from the Microsoft.Extensions.Logging library and are running into an issue utilizing the Message Template format with the Logger.LogError method and with the string.Format method. See use case below.

string message2 = "{User} not found";
this.logger.LogError(message2, user);
return message;

In this case, we're creating a custom dimension for the user in our logs but the message returned to our user would be "{User} not found". If we tried to utilize the string.Format method it fails because it expects string.format("{0}", user). Atm I've written a custom extension method to parse this out but I'd imagine this is a use case for everyone following this pattern. Could this be included as another overload for string.Format in the future or possibly a different method altogether?

Thnx

[huoyaoyuan]

So effectively, you are asking for replacing placeholder indexes with names.
This is not easy for string.Format, since there's no way to pass names into it.

Generally we are suggesting moving away from string.Format to reduce overhead. Starting from C# 10, interpolated strings ($"{user} not found") will have less overhead than string.Format. The difference is more for logging since the formatting won't actually be done if logging is disabled.

[SerratedSharp]

Sometimes that's viable, but often string.Format use cases cannot leverage interpolation. If templates are stored in a resx or database, then making the replacements requires string.Format with numbered placeholders, or usage of a library that supports named placeholders like dotliquid.

[huoyaoyuan]

Yes I agree with this. My team is also using DotLiquid heavily. A built-in more efficient solution would be nice.

[davidfowl]

@stephentoub Thoughts? Should we expose LogValuesFormatter. I'm not sure how common this scenario is.

[stephentoub]

I don't know how common it is, either. We could consider exposing it, though probably with someone spending some time to propose the actual surface area to be made available; right now the internal surface area that's provided differs based on the target framework. I'm also not super keen on adding yet another class with formatting APIs that look like string.Format, CompositeFormat, etc.; I'd be more inclined to see this just be what's necessary, e.g. a method that produces the composite format string and a list of the names, or something like that, and then leave the actual formatting support to be done by existing APIs.

[davidfowl]

I'd be more inclined to see this just be what's necessary, e.g. a method that produces the composite format string and a list of the names, or something like that, and then leave the actual formatting support to be done by existing APIs.

I like this idea. On CompositeFormat maybe?

[stephentoub]

Not sure where the best place would be, but yeah, that's possible. The concept of the placeholders being something other than the index of the argument is unique to the logging APIs, so it feels a little out of place to me to propagate that to CompositeFormat, but if we can't find a better place for it. Maybe on LoggerMessage?

[SpaceOgre]

I just stumble upon this when looking for a way to use named placeholders for string.Format. My use case is a bit different so I wanted to chime in as well.

I have API routes defined as constant strings and the route parameters:

    public const string RouteParameterOperationId = "operationId";
    public const string Route = $"/operations/{{{RouteParameterOperationId}}}/permitfile";

Then I want to use the Route field in a string.Format call: string.Format(Route, new Guid()) but this does not work.

I still want to keep the route parameter name and not change it to 0 since that would make it look weird in the API description etc, and I would also like to not have to duplicate the route format since that might introduce inconsistencies and is the reason for the const string field in the first place.