Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
[main] Update dependencies from dotnet/arcade #6711
[main] Update dependencies from dotnet/arcade #6711
Changes from 9 commits
27cfef9
a81f429
3e806d8
0dd95e8
1ed51c3
f43788e
b612daf
fccce76
b6e19f1
fe5c14c
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
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.
I'm still unclear on whether it's ok to make this change in the .NET Framework version of MSBuild where this API is available and works. Can you elaborate on your reasoning there?
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.
AssemblyNameExtension is internal, so customers can't use it without making a custom MSBuild. We don't rely on the KeyPair part because otherwise, the .net 6 code wouldn't run. So we don't need KeyPair, and customers can't need KeyPair, so we should be able to remove it and stop serializing/deserializing it.
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.
This doesn't obviously follow for me. I get that we don't need it on .NET 6+. But it's never used/compared in .NET Framework scenarios?
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.
I won't say I took a deep look at every use, but I tried to briefly look at all our uses (outside tests) to see if they were #ifdef'd on platform, and the ones that were didn't seem to use StrongNameKeyPair. I was a little thrown by "GetPublicKeyToken" and wondered if that was a use, but it seems to still exist on .net 6 without throwing deprecated warnings, so I think it's something else. If you want me to, I can put the removal under an ifdef'd change wave or, if it makes you really uncomfortable, just ifdef it out, but then we may be serializing and deserializing something on .net framework for no reason.
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.
Ok, I think this is what I was looking for (from https://docs.microsoft.com/en-us/dotnet/api/system.reflection.assemblyname.keypair?view=net-5.0#remarks):
Since we use this in RAR, which is not interested in dynamic assemblies, it will always be
null
, so dropping it is ok.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.
Instead of doing this, can you follow the guidance on this warning? https://docs.microsoft.com/en-us/dotnet/core/compatibility/code-analysis/5.0/ca1416-platform-compatibility-analyzer#recommended-action
Specifically, I'd expect to see this call annotated with
[SupportedOSPlatform("windows")]
, which will require annotating or conditionalizing up the chain.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.
The guidance I followed is right below the guidance you suggested.
Also, [SupportedOSPlatform("windows")] was introduced in .net 6, as was OperatingSystem.IsWindows(), so I would have to ifdef around the attribute or IsWindows check. That's pretty terrible, so I don't think that's a good idea.
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.
At the very least this needs a comment.
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.
I can add one. It doesn't change anything, but I should correct myself: it was introduced in .net 5, not .net 6.