-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Backward-compatibility with KeyValuePair<string, string> metadata items [#8864] #8870
Conversation
@dotnet-policy-service agree |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now that I understand the problem, I'm not sure this fix is sufficient; there could theoretically be an ITaskItem
implementation that returned a totally custom type with non-KVP non-DictionaryEntry backing for its IEnumerable
implementation.
Taking this would certainly cover the likely implementations, but I'm starting to think we should go back to the foreach
for this fallback code path.
(oh and also . . . thanks for the PR!) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a few minor comments.
7b58e87
to
a4e179d
Compare
@donJoseLuis @rainersigwald I have updated the PR based on the suggestions to use P.S. Do we care that we are assuming all DictionaryEntry's will be <string, string>? |
No, that's ok--it's the only thing that would ever have worked AFAIK. |
Updated to loop DictionaryEntry's in the foreach. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for diving into this!
If the call to SetMetadata
is intentionall - please explain the reasoning in the description.
Without that - it looks good to go
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One more small nit (we can avoid reallocations by specifying the size of the list up front). Thanks for working through this, it's looking great!
@JaynieBai, could you please write a test for this case? We'll need a task that returns a custom ITaskItem
implementation that has a custom IDictionary
type returned from CloneCustomMetadata()
.
Co-authored-by: Rainer Sigwald <raines@microsoft.com>
Yeah, I will do that |
@rainersigwald - all expressed concerns seem to be addressed - do you want to revise? |
/backport to vs17.7 |
Started backporting to vs17.7: https://github.com/dotnet/msbuild/actions/runs/5415050762 |
Diff: https://github.com/dotnet/msbuild/compare/24ee0c75a7c5a9924c68157ae7f8e0ce6c9adca3..e2e438ef48eec8cf83d81cfc66cf3bb363ff5513 From: dotnet/msbuild@24ee0c7 To: dotnet/msbuild@e2e438e Commits: - [main] Update dependencies from dotnet/arcade (#9059) dotnet/msbuild@881abda - Merge pull request #9066 from JanKrivanek/proto/tl-dotnettests-disable dotnet/msbuild@fd4d0e5 - Add unit test for dotnet/msbuild#8870 (#8961) dotnet/msbuild@6c1bb22 - fixes dotnet/msbuild#8958 TerminalLogger in .NET 8.0.100-preview.6 issues audible alerts on iTerm2 (#9060) dotnet/msbuild@ce59c70 - TaskFactoryWrapper: guard against multi-threaded access to dictionaries (#8928) dotnet/msbuild@edeacbb - Resource for invalid -tl value (#9078) dotnet/msbuild@e2e438e [[ commit created by automation ]]
Fixes #8864
Context
TaskExecutionHost.cs
Changes Made
Fallback to the prior behavior of expecting metadata items of type KeyValuePair<string, string>
Testing
This has not been tested