Reverting: Set AssemblyName.ProcessorArchitecture for compatibility (#80581) #84028
Conversation
ghost
assigned 
|
Tagging subscribers to this area: @dotnet/area-system-reflection Issue DetailsThis is a revert of #80581 Also see: [release/7.0] Reverting: Set AssemblyName.ProcessorArchitecture for compatibility (#81101)
The attempt to make the behavior closer to the native implementation in #80581 caused more issues than the original minor compat break that it tried to fix. Customer ImpactAfter the original change an application that obtain AssemblyName from assembly files may get ProcessorArchitecture set, which could be now unexpected when the name is subsequently used. For example a scenario when an app scans assemblies in a folder used to work prior the original "fix" may now fail with: See: #83526 We think that the original fix does not precisely replicate the .NET desktop behavior. However, trying to replicate the exact deprecated API behavior seems very difficult. For instance, the API doesn't support ARM64, so we would have to somehow provide back-compat for a deprecated API even as our product evolves in a way that the original API can't support and we don't want to evolve. There are also similar issues reported directly by internal teams updating to 7.0.201. TestingWe have regression tests for this feature and they were updated as a part of this change. Our understanding of the "modern" API set is quite good, compared to the deprecated set.
|
| #pragma warning restore SYSLIB0037 | ||
| } | ||
|
|
||
| private static ProcessorArchitecture CalculateProcArch(PortableExecutableKinds pek, ImageFileMachine ifm, AssemblyNameFlags aFlags) | ||
| private static ProcessorArchitecture CalculateProcArchIndex(PortableExecutableKinds pek, ImageFileMachine ifm, AssemblyNameFlags flags) | ||
| { |
There was a problem hiding this comment.
I think we can keep this part as is. It is simpler, it has better comments, and it is functional equivalent to the old code.
There was a problem hiding this comment.
Ideally, we would delete this and just return ProcessorArchitecture.None to be in sync with the S.R.M implementation, It is probably not worth it to spend time on pushing the breaking change through - we can keep these ~20 lines for compat.
There was a problem hiding this comment.
Ideally, we would delete this and just return ProcessorArchitecture.None to be in sync with the S.R.M
Actually, since we are breaking this one way or another, maybe we should break this all the way and just return None ?
There is some time in 8.0 to see if this gets anyone in trouble.
|
the wasm failure is #83655 |
|
Thanks! |
This is a revert of #80581
Also see: [release/7.0] Reverting: Set AssemblyName.ProcessorArchitecture for compatibility (#81101)
AssemblyName.ProcessorArchitectureis unnatural concept in CoreCLR (and thus the property is deprecated).The attempt to make the behavior closer to the native implementation in #80581 caused more issues than the original minor compat break that it tried to fix.
Customer Impact
After the original change an application that obtain AssemblyName from assembly files may get ProcessorArchitecture set, which could be now unexpected when the name is subsequently used.
For example a scenario when an app scans assemblies in a folder used to work prior the original "fix" may now fail with:
See: #83526
We think that the original fix does not precisely replicate the .NET desktop behavior. However, trying to replicate the exact deprecated API behavior seems very difficult. For instance, the API doesn't support ARM64, so we would have to somehow provide back-compat for a deprecated API even as our product evolves in a way that the original API can't support and we don't want to evolve.
There are also similar issues reported directly by internal teams updating to 7.0.201.
Testing
We have regression tests for this feature and they were updated as a part of this change. Our understanding of the "modern" API set is quite good, compared to the deprecated set.