[release/7.0] Reverting: Set AssemblyName.ProcessorArchitecture for compatibility (#81101)

[VSadov]

This is a revert of #81101

AssemblyName.ProcessorArchitecture is unnatural concept in CoreCLR (and thus the property is deprecated).

The attempt to make the behavior closer to the native implementation in #81101 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:

Loading assembly: LoadAssemblyBug, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
Loading assembly: Microsoft.AspNetCore.Antiforgery, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60
Could not load file or assembly 'Microsoft.AspNetCore.Antiforgery, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60, processorArchitecture=AMD64'. The system cannot find the file specified.

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.

Risk

The change itself has low risk. We are reverting another change.

We also need to acknowledge that the state we are reverting has compat differences with .NET FX and 6.0, which at this point seems preferable.

[ghost]

Tagging subscribers to this area: @dotnet/area-system-reflection-metadata
See info in area-owners.md if you want to be subscribed.

Issue Details

---

This is a revert of #81101

AssemblyName.ProcessorArchitecture is unnatural concept in CoreCLR (and thus the property is deprecated).
The attempt to make the behavior closer to the native implementation in #81101 caused more issues than the original compat break that it tried to fix.

See: #83526
There are also issues reported directly by a few internal teams updating to 7.0.201.

TODO: fill the template

Author:	VSadov
Assignees:	VSadov
Labels:	area-System.Reflection.Metadata
Milestone:	-

[jkotas]

Are we going to revert it in main as well?

[VSadov]

Are we going to revert it in main as well?

yes.

the change in main was a bit bigger - not just metadata reader, but also AssemblyName.CoreCLR. Not sure yet which way that should be changed.

[jkotas]

AssemblyName.CoreCLR. Not sure yet which way that should be changed.

I think it would be best to make it match System.Reflection.Metadata.

[agocke]

Code change LGTM. Please fill out the template

[jeffschwMSFT]

approved. we will take for consideration in 7.0.x

[carlossanlop]

The OOB package authoring changes look good.

[carlossanlop]

Reminder: April 10th is the last day to merge backport PRs to ensure they get included in the May Release. PR owners are now in charge of merging their own PRs.

[carlossanlop]

I re-targeted this PR to the new release/7.0-staging branch, which is the one that we will use from now on for servicing fixes.

PR owners will now be expected to merge their own servicing PR. The new process is described here: runtime/docs/project/library-servicing.md.

The infra team will be actively monitoring servicing PRs as usual to help with any issues.

@VSadov if you're not waiting for anything else, you can merge anytime, your PR meets all the requirements. Here is the checklist for future reference:

• Approved by Tactics and Servicing-approved label applied (check-service-labels CI action is passing).
• Signed-off by at least one area owner.
• If the change affects a nuget package, the required OOB changes are included.
• CI failures are unrelated (Platform_TimeZoneNames failing for Iran time zones on macOS #83901).

[VSadov]

@carlossanlop - thanks!! I'll merge it then.