Add support for improved TaskParameterEventArgs#780
Add support for improved TaskParameterEventArgs#780KirillOsenkov merged 2 commits intoKirillOsenkov:mainfrom
Conversation
| if (errorByType.Any(i => i != 0)) | ||
| { | ||
| string summary = string.Join(", ", errorByType.Where((count, index) => count > 0).Select((count, index) => $"{((ReaderErrorType)index)}: {count}")); | ||
| string summary = string.Join(", ", errorByType.Where((count, index) => count > 0).Select((count, index) => $"{((ReaderErrorType)index)}: {count} cases")); |
There was a problem hiding this comment.
I'm finding the existing message confusing. For example, Skipped some data unknown to this version of Viewer. 7 cases encountered (UnknownEventType: 7). to me suggests that 7 is the event type. Making it clearer that the number is the count.
There was a problem hiding this comment.
Indeed very confusing. Thanks!
| private static Action<BuildMessageEventArgs, int> lineNumberSetter = GetFieldSetter<BuildMessageEventArgs, int>("lineNumber"); | ||
| public static void SetLineNumber(BuildMessageEventArgs args, int lineNumber) | ||
| { | ||
| lineNumberSetter(args, lineNumber); | ||
| } | ||
|
|
||
| private static Action<BuildMessageEventArgs, int> columnNumberSetter = GetFieldSetter<BuildMessageEventArgs, int>("columnNumber"); | ||
| public static void SetColumnNumber(BuildMessageEventArgs args, int columnNumber) | ||
| { | ||
| columnNumberSetter(args, columnNumber); | ||
| } | ||
|
|
There was a problem hiding this comment.
I don't think we need this anymore as TaskParameterEventArgs2 contains new props representing line and column number.
8a5a4b3 to
92890ba
Compare
JanKrivanek
left a comment
There was a problem hiding this comment.
This looks good to me - simple and effective. Thank you!
| if (errorByType.Any(i => i != 0)) | ||
| { | ||
| string summary = string.Join(", ", errorByType.Where((count, index) => count > 0).Select((count, index) => $"{((ReaderErrorType)index)}: {count}")); | ||
| string summary = string.Join(", ", errorByType.Where((count, index) => count > 0).Select((count, index) => $"{((ReaderErrorType)index)}: {count} cases")); |
There was a problem hiding this comment.
Indeed very confusing. Thanks!
| if (line != 0) | ||
| { | ||
| Reflector.SetLineNumber(args, line); | ||
| } | ||
|
|
||
| if (column != 0) | ||
| { | ||
| Reflector.SetColumnNumber(args, column); | ||
| } | ||
|
|
||
| // Should probably make these public | ||
| // args.LineNumber = line; | ||
| // args.ColumnNumber = column; | ||
| args.LineNumber = line; | ||
| args.ColumnNumber = column; |
|
Published https://github.com/KirillOsenkov/MSBuildStructuredLog/releases/tag/v2.2.243 - please try it out to make sure it all works as expected. Thanks! |
|
@KirillOsenkov I have tested it on version 2.2.248 and all seems to be good. Please confirm that it's OK to merge the MSBuild PR now. |
|
yes, go ahead |
Contributes to #9881 ### Context When `TaskParameterEventArgs` represents an output parameter of a task, it currently does not capture the name of the parameter. This information is generally useful as multiple output parameters can be assigned to the same item, and it's important for the BuildCheck infrastructure to provide a consistent object model to build analyzers. Additionally, output parameters that are assigned to properties are currently logged as textual log messages `Output Property: {0}={1}` which miss the name of the parameter as well. ### Changes Made Added two new properties on the `TaskParameterEventArgs` class, including the requisite serialization support. Updated logging to populate the properties with the name of the task parameter and the name of the build property, respectively, and updated BuildCheck infra to expose it to analyzers subscribed to task parameter events. All task parameters are now logged as the structured `TaskParameterEventArgs` and the kind of parameter (input, output to property, output to item) can be determined by examining the args. ### Testing - Tweaked existing unit test and updated the relevant BuildCheck test. - Verified that when using the standard console logger, the resulting textual log is identical. - Verified that binlog viewer without the corresponding changes displays the forward-compat warning about unknown data. ### Notes - Complementary binlog viewer PR: KirillOsenkov/MSBuildStructuredLog#780 - The change is behind a changewave because it is technically a breaking change for third party loggers. Co-authored-by: Rainer Sigwald <raines@microsoft.com>
dotnet/msbuild#10130 is making MSBuild log
TaskParameterEventArgsfor all task parameters, including all output parameters. This PR adds support for this format change to the viewer.Changes
TaskParameterEventArgsused for all parameters.Testing
Old binlog with new viewer - no changes.
New binlog with old viewer - shows the
Skipped some data unknown to this version ...warning and misplaces output parameters assigned to properties. They are incorrectly displayed underOutputItemswithN/Aname.This is assumed to be an acceptable break for users who haven't updated to the new version.
This is just a quick proof-of-concept as I'm not sure what the best way of presenting this data is or if there's appetite for enriching the UI at all. We could certainly not show the parameter name anywhere for now.