Make query parameter format for logging consistent #8456
Labels
closed-fixed
The issue has been fixed and is/will be included in the release indicated by the issue milestone.
type-enhancement
Milestone
Comments
ajcvickers
added a commit
that referenced
this issue
May 13, 2017
Issue #6946 The T4 template for resource strings has been updated so that if the resource name starts with "Log", then we generate an EventDefinition using information from the comment section. This brings together the event ID, log-level, and a typed, cached delegate that can be called to log the event to an ILogger. It also contains a mechanism to generate the message for use when testing and when throwing warnings-as-errors. All the XxxLoggerExtensions class now use this mechanism. As part of this, IInterceptingLogger was consolidated into IDiagnosticsLogger. There are no longer any Log methods here because logging is done through the definitions using the cached delegates. A fallback mechanism--RawEventDefinition--can be used for messages with more than six parameters. There are only a handful of these, and they are for design-time scenarios and so don't need to be super fast. Part of #218 Also, see #8456
ajcvickers
added a commit
that referenced
this issue
May 15, 2017
Issue #6946 The T4 template for resource strings has been updated so that if the resource name starts with "Log", then we generate an EventDefinition using information from the comment section. This brings together the event ID, log-level, and a typed, cached delegate that can be called to log the event to an ILogger. It also contains a mechanism to generate the message for use when testing and when throwing warnings-as-errors. All the XxxLoggerExtensions class now use this mechanism. As part of this, IInterceptingLogger was consolidated into IDiagnosticsLogger. There are no longer any Log methods here because logging is done through the definitions using the cached delegates. A fallback mechanism--RawEventDefinition--can be used for messages with more than six parameters. There are only a handful of these, and they are for design-time scenarios and so don't need to be super fast. Part of #218 Also, see #8456
ajcvickers
added a commit
that referenced
this issue
May 28, 2017
…ines Issue #8456 We previously used a different format for parameter logging in our tests when compared to product code logging. Now we use the same format everywhere. This change updates the product format back to what it was, and updates the test baselines to reflect this.
ajcvickers
added
the
closed-fixed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In our tests, parameters were logged like this:
[param: 17]In production logs, they were logged like this:
[param='17']This is because we had different code generating the strings in each case. With the fix for #6946, there is only now one piece of code. It generates logs like we have been doing for our tests, because doing otherwise would result in massive baseline updates. However, if we decide to go with a different format, then we can do the work. 👷
The text was updated successfully, but these errors were encountered: