[release/7.0] Set AssemblyName.ProcessorArchitecture for compatibility.

[github-actions]

Fixes: #77697

Partial backport of #80581 to release/7.0
Backport of #80878 (test fix)

Includes only metadata reader fixes. The consistency changes to AssemblyName.CoreCLR are not ported to reduce risk of incompatibilities in a servicing release.

Customer Impact

Moving assembly name parsing to unified managed implementation unintentionally omitted computing ProcessorArchitecture.
Even though the ProcessorArchitecture is a deprecated API, it was a breaking change in some rare scenarios.

This change brings back a simplified form of computing ProcessorArchitecture.

"Simplified" here is that we do not handle completely broken/not-loadable assemblies. In those cases we return default value. This should be sufficient to satisfy the scenarios that still use this, otherwise deprecated, API.

Testing

A test was added and is backported together with this change.

Risk

Low. We are reintroducing an implementation of an API instead of always returning a default value.

[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

---

Backport of #80581 to release/7.0

/cc @VSadov

Customer Impact

Testing

Risk

IMPORTANT: Is this backport for a servicing release? If so and this change touches code that ships in a NuGet package, please make certain that you have added any necessary package authoring and gotten it explicitly reviewed.

Author:	github-actions[bot]
Assignees:	-
Labels:	area-System.Reflection.Metadata
Milestone:	-

[jkotas]

This is touching System.Reflection.Metadata that also ships as independent nuget package. I think you need include packaging authoring change as part of the PR to make sure that we ship a new version of System.Reflection.Metadata package.

[VSadov]

I think you need include packaging authoring change as part of the PR

Are there examples how this is done? We probably did this before.

[jkotas]

https://github.com/dotnet/runtime/blob/main/docs/project/library-servicing.md

[jkotas]

https://github.com/dotnet/runtime/search?q=library-servicing.md&type=issues shows examples where this was done before

[ericstj]

Do we think this might reintroduce warnings in MSBuild in servicing? While that might be desirable, we should probably call that out as a risk. cc @rainersigwald

[rainersigwald]

Do we think this might reintroduce warnings in MSBuild in servicing? While that might be desirable, we should probably call that out as a risk. cc @rainersigwald

This is a good concern but I think it's ok.

This will reactivate the longstanding MSBuild codepath that covers the non-ProcessorArchitecture.None scenario, so it could raise an error that running on the 7.0.0 runtime wouldn't.

Mitigations:

1. It was like this for previous releases.
2. It is still like this for .NET Framework MSBuild (i.e. Visual Studio-driven builds).
3. There is a property that can be set to avoid the warning/error (<ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>none</ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>)
4. I think it's generally desired behavior.

[ericstj]

Got it, do you think we should up the risk to "medium" and plan for documentation (release notes) that warn folks about this?

[ghost]

Added needs-breaking-change-doc-created label because this PR has the breaking-change label.

When you commit this breaking change:

1. Create and link to this PR and the issue a matching issue in the dotnet/docs repo using the breaking change documentation template, then remove this needs-breaking-change-doc-created label.
2. Ask a committer to mail the .NET Breaking Change Notification DL.

Tagging @dotnet/compat for awareness of the breaking change.

[rainersigwald]

Per tactics we need a relnote. It should ideally link to https://learn.microsoft.com/visualstudio/msbuild/errors/msb3270, which has docs on the error and property.

[ericstj]

Conclusion from tactics was "yes" to my question above. Let's file the breaking change doc for this - warning folks that the fix will bring back the warning. We should tag @rbhanda in that breaking change issue to ensure the details get added to servicing release notes.

[VSadov]

Conclusion from tactics was "yes" to my question above. Let's file the breaking change doc for this - warning folks that the fix will bring back the warning. We should tag @rbhanda in that breaking change issue to ensure the details get added to servicing release notes.

Just to make sure - do I need to do the above or it will be someone who better understands what the msbuild issue is about, or the committer of this change?

[carlossanlop]

Approved by Tactics for 7.0.4.
Signed off by area owners.
Required OOB package authoring changes look good.
CI failures unrelated: #81544
Ready to merge.