Restore Microsoft.Build binary compatibility for relocated communication types

[Copilot]

Work item (Internal use):

Summary

MSB4236 regressions were triggered by relocating communication/XMake types from Microsoft.Build to Microsoft.Build.Framework without forwarding legacy type identities. In mixed-load host scenarios (notably MSBuildLocator-based hosts), this can surface as SDK resolver fallthrough and MSB4236.

• Type-forwarder restoration
  • Added missing TypeForwardedTo entries in src/Build/AssemblyInfo.cs for:
    • Microsoft.Build.Internal.Handshake
    • Microsoft.Build.Internal.HandshakeComponents
    • Microsoft.Build.Internal.HandshakeOptions
    • Microsoft.Build.Internal.HandshakeStatus
    • Microsoft.Build.Internal.ServerNodeHandshake
    • Microsoft.Build.BackEnd.INodePacket
    • Microsoft.Build.BackEnd.NodePacketType
    • Microsoft.Build.BackEnd.NodePacketTypeExtensions
    • Microsoft.Build.Internal.CommunicationsUtilities
    • Microsoft.Build.Shared.XMakeAttributes
    • Microsoft.Build.Shared.XMakeElements
• Regression coverage
  • Added src/Build.UnitTests/BackEnd/TypeForwarding_Tests.cs to assert these forwarded identities are present in typeof(BuildManager).Assembly.GetForwardedTypes().

[assembly: TypeForwardedTo(typeof(Microsoft.Build.Internal.Handshake))]
[assembly: TypeForwardedTo(typeof(Microsoft.Build.BackEnd.INodePacket))]
[assembly: TypeForwardedTo(typeof(Microsoft.Build.Shared.XMakeElements))]

Customer Impact

Restores binary compatibility for hosts that still resolve these type tokens against Microsoft.Build.dll, preventing resolver-chain TypeLoadException paths that manifest as false SDK-not-found (MSB4236) failures.

Regression?

Yes. Introduced when types were moved from Microsoft.Build to Microsoft.Build.Framework without matching forwarders.

Testing

Added a focused unit test validating that the expected forwarded types are emitted by Microsoft.Build.

Risk

Low. Scope is limited to assembly-level type forwarding metadata and targeted compatibility test coverage.

[dotnet-policy-service]

Hello @copilot, I noticed that you’re changing an .swr file or any file under src/Package/MSBuild.VSSetup.. Please make sure to validate this change by an experimental VS insertion. This is accomplished by pushing to an exp/* branch, which requires write permissions to this repo.

[DustinCampbell]

@baronfel: I think this can be closed with #13804.