Use MSBuild task instead of Exec for PublishDotnetAot

[dsplaisted]

Summary

Replace the <Exec> of dotnet publish in PublishDotnetAot with an in-process <MSBuild Targets="Publish" ...> task call. The Exec was the root cause of the dotnet-unified-build internal regression on dnceng/internal (build 2972531) — see error details below.

Root cause

The Exec-based child dotnet publish introduced by dotnet/sdk#54222 and adjusted by 73010df (manual VMR fix removing --no-restore) spawned a fresh MSBuild process to publish dotnet-aot.csproj. The child process:

1. Did not inherit the outer build's MSBuild global properties (DotNetBuild=True, DotNetBuildFromVMR=True, Arcade / source-build flags, DebugType, signing, version overrides, etc.).
2. Re-Built dotnet-aot.csproj's ProjectReferences — Microsoft.DotNet.Cli.Utils, Cli.CoreUtils, NativeWrapper — from scratch with different evaluated properties.
3. Clobbered the PDBs the outer build had produced, writing them with different DebugType/symbol settings (or not producing them at all).

The outer build's subsequent Copy and Pack steps then failed:

MSB3030: Could not copy the file
  "...\artifacts\bin\Microsoft.DotNet.Cli.CoreUtils\Release\net11.0\Microsoft.DotNet.Cli.CoreUtils.pdb"
because it was not found.

NU5026: The file
  "...\artifacts\bin\Microsoft.DotNet.Cli.Utils\Release\net11.0\Microsoft.DotNet.Cli.Utils.pdb"
to be packed was not found on disk.

This regression doesn't surface in dotnet/sdk public CI because public CI doesn't run the source-build Copy/Pack steps that consume those PDBs — the clobber still happens, it's just invisible.

Why an in-process <MSBuild> task fixes it

An in-process <MSBuild Targets="Publish" ...> call shares the outer build's BuildManager. When that call needs dotnet-aot.csproj's ProjectReferences, the BuildManager sees they were already built earlier in the same session (matching Configuration and global properties) and returns the cached results instead of rebuilding. The PDBs from the outer build stay intact.

Why this does NOT bring back NETSDK1112 (Marc's stated reason for removing --no-restore)

Verified directly from the failing build's sdk binlog (Windows_x64_BuildLogs_Attempt1/artifacts/log/Release/sdk/Build.binlog from build 2972531):

• The centralized sdk.slnx restore in the VMR is RID-aware. The SolutionRestore evaluation of dotnet-aot.csproj has RuntimeIdentifier=win-x64 (flowing from the conditional declaration in dotnet-aot.csproj added in Fix PublishDotnetAot non-deterministic NETSDK1047 with RestoreForce sdk#54222).

• ProcessFrameworkReferences on dotnet-aot.csproj during the SolutionRestore evaluation logs:

  Adding tool pack ILCompiler for runtime 11.0
  ...
  Added ILCompiler runtime pack 'runtime.win-x64.Microsoft.DotNet.ILCompiler@11.0.0-preview.5.26261.113'
  Checking for cross-targeting compilation packs for win-x64
  Added Microsoft.NETCore.App.Runtime.NativeAOT.win-x64@11.0.0-preview.5.26261.113 for cross-targeting compilation for win-x64
  Added PackageDownload for Microsoft.NETCore.App.Runtime.NativeAOT.win-x64@11.0.0-preview.5.26261.113 for cross-targeting compilation for win-x64
  

• The pack lands on disk at artifacts/.packages/microsoft.netcore.app.runtime.nativeaot.win-x64/11.0.0-preview.5.26261.113.

So the NativeAOT runtime pack is reliably present after the centralized restore — no separate Restore call is needed. The previous "Restore is NOT skipped here because runtime packs are only downloaded during a RID-aware restore" rationale was based on a misdiagnosis: the actual VMR failure was the PDB clobber, not missing runtime packs.

Validation

• Locally validated the equivalent fix on dotnet/sdk main with a clean build.cmd -ci -c Release: 0 errors, AOT shared library (dotnet-aot.dll) produced and placed in the SDK layout as expected.
• Full VMR build not run locally (impractical). A private dotnet-unified-build run from this PR is the right validation; the binlog evidence above makes the fix high-confidence.

cc @marcpopMSFT (who authored the previous VMR manual fix 73010df — the NU5026/MSB3030 in build 2972531 is what motivated finding the real root cause)

[Copilot]

Pull request overview

This PR updates the SDK layout build to publish the dotnet-aot NativeAOT shared library using an in-process <MSBuild Targets="Publish" ...> invocation instead of spawning a separate dotnet publish process via <Exec>. This aligns the publish with the outer build’s BuildManager session (and its global properties), addressing the reported internal unified-build regression where a child publish rebuilt project references under different settings and clobbered previously produced PDBs.

Changes:

• Replace the dotnet publish <Exec> in PublishDotnetAot with an in-proc <MSBuild Targets="Publish" ...> call.
• Update the surrounding comment to document why in-proc publish is required and why a separate restore isn’t needed in this context.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[ericstj]

Will this target/MSBuild call ever race with another build of this project? This shares many of the same directories for the configuration, but's being built with different global properties, which break MSBuild's project build cache. It might be OK if it never races with the actual project build.

[dsplaisted]

Will this target/MSBuild call ever race with another build of this project? This shares many of the same directories for the configuration, but's being built with different global properties, which break MSBuild's project build cache. It might be OK if it never races with the actual project build.

I've fixed this so that it no longer sets any global properties on the call to Publish. I think this will probably fix the issues.

/cc @NikolaMilosavljevic @ViktorHofer @MichaelSimons @JeremyKuhne

[ericstj]

This looks better.

[MichalStrehovsky]

Running the Publish target directly without also setting the _IsPublishing property to true has been a source of subtle issues in the past because just running the Publish target is not enough to get all the behaviors.