Fix NativeAOT publish including satellite assemblies despite embedding them

[Copilot]

Description

NativeAOT embeds satellite assemblies into the native binary but still copies them to the publish folder. After PR #124801 refactored the NativeAOT build integration to work with ResolvedFileToPublish directly, this fix removes project satellite assemblies from that item group.

Fix: Add removal of IntermediateSatelliteAssembliesWithTargetPath from ResolvedFileToPublish in the ComputeLinkedFilesToPublish target:

<ItemGroup>
  <ResolvedFileToPublish Remove="@(_IlcManagedInputAssemblies)" />
  <!-- dotnet CLI produces managed debug symbols, which we will replace with native symbols instead -->
  <ResolvedFileToPublish Remove="@(_DebugSymbolsIntermediatePath)" />
  <!-- Satellite assemblies are embedded into the native binary, so we don't need to publish them -->
  <ResolvedFileToPublish Remove="@(IntermediateSatelliteAssembliesWithTargetPath)" />
  <!-- replace apphost with binary we generated during native compilation -->
  <ResolvedFileToPublish Include="$(NativeBinary)">
    <RelativePath>$(NativeBinaryPrefix)$(TargetName)$(NativeBinaryExt)</RelativePath>
    <CopyToPublishDirectory>PreserveNewest</CopyToPublishDirectory>
  </ResolvedFileToPublish>
</ItemGroup>

This follows the same pattern as removing managed assemblies and debug symbols, which are also embedded or replaced in the native binary.

Customer Impact

• Affected customers: NativeAOT users with localized resources
• Regression: No
• Source incompatibility: No
• Breaking change: No (removes extraneous files from publish output)

Testing

Testing will be added in the SDK repo per review feedback. The fix can be validated by publishing a NativeAOT app with satellite assemblies and verifying that:

• Localized resources are accessible at runtime (embedded correctly)
• No satellite assembly subdirectories exist in publish output

Risk

Minimal. One-line change following established pattern. Satellite assemblies remain embedded and functional; only removes redundant disk copies.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>AOT publish includes satellite assemblies in publish folder</issue_title>
<issue_description>### Describe the bug
Publishing an AOT app will include satellite resource assemblies (for example <language>\AppName.resources.dll in the output folder. It appears that these are also embedded in the NativeAOT executable, the app can still show localized strings even if these are deleted.

Ideally if these satellite assemblies are not needed, they should not be copied to the publish folder. As it is, it's confusing and makes it look like they need to be deployed with the app.

To Reproduce

• Create a console app
• Set PublishAot to true in the .csproj file
• Add a resx file and a localized resx file with a string resource in them (for example Strings.resx and Strings.es.resx)
• Publish the app

Expected: No language subfolders and satellite assemblies in the publish folder

Actual: Language subfolders with satellite assemblies are present in the publish folder

Repro project

Binlog

Further technical details

.NET SDK version: 10.0.102</issue_description>

<agent_instructions>Fix this bug. Pay attention to the analysis from @baronfel about how to fix it.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

@baronfel I gave this problem to Copilot CLI equipped with the viktorhofer/dotnet-skills plugin, and here was its analysis after publishing + inspecting the binlog:

Root Cause Analysis

The satellite assemblies (e.g. es\AppName.resources.dll) end up in the NativeAOT publish output because the NativeAOT build integration correctly embeds them into the native binary but fails to remove them from the publish file list, so the SDK's generic publish pipeline copies them to the output directory anyway.

How satellite assemblies flow through the pipeline

Step 1: NativeAOT collects satellite assemblies for embedding

In Microsoft.NETCore.Native.Publish.targets (dotnet/runtime), _ComputeIlcCompileInputs gathers satellite assemblies from two sources:

<IlcSatelliteAssembly Include="@(_SatelliteAssembliesToPublish)" />
<IlcSatelliteAssembly Include="@(IntermediateSatelliteAssembliesWithTargetPath)" />

• _SatelliteAssembliesToPublish = satellite assemblies from package/project references (extracted from _ResolvedCopyLocalPublishAssets by ComputeManagedAssembliesToCompileToNative)
• IntermediateSatelliteAssembliesWithTargetPath = the project's own satellite assemblies (e.g. es\52913-resx-in-nativeaot.resources.dll)

These are passed to ILC via --satellite: in Microsoft.NETCore.Native.targets, which embeds them into the native binary. This part works correctly — the app can resolve localized strings even if the satellite DLLs are deleted from disk.

Step 2: ComputeLinkedFilesToPublish cleans up the publish list — but misses the project's own satellites

ComputeLinkedFilesToPublish runs BeforeTargets="ComputeResolvedFilesToPublishList" and modifies the publish list:

<_ResolvedCopyLocalPublishAssets Remove="@(_AssembliesToSkipPublish)" />  <!-- removes package satellites -->
<_ResolvedCopyLocalPublishAssets Include="@(_LinkedResolvedAssemblies)" />
<_DebugSymbolsIntermediatePath Remove="@(_DebugSymbolsIntermediatePath)" />

<IntermediateAssembly Remove="@(IntermediateAssembly)" />  <!-- replaces managed .dll with native binary -->
<IntermediateAssembly Include="$(NativeBinary)" />

This successfully removes package-reference satellite assemblies (via _AssembliesToSkipPublish) and replaces the managed assembly with the native binary. But it does NOT remove IntermediateSatelliteAssembliesWithTargetPath.

Step 3: The SDK unconditionally re-adds the project's satellite assemblies to publish

In Microsoft.NET.Publish.targets (dotnet/sdk), ComputeResolvedFilesToPublishList unconditionally includes:

<!-- Copy satellite assemblies. -->
<ResolvedFileToPublish Include="@(IntermediateSatelliteAssembliesWithTargetPath)">
  <RelativePath>%(IntermediateSatelliteAss...

</details>



<!-- START COPILOT CODING AGENT SUFFIX -->

- Fixes dotnet/runtime#124191

<!-- START COPILOT CODING AGENT TIPS -->
---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more [Copilot coding agent tips](https://gh.io/copilot-coding-agent-tips) in the docs.

[baronfel]

@nagilson @agocke here is that PR about NAOT and satellite assemblies.

[agocke]

@sbomer has been refactoring the targets so I'm not sure if there's a better place for this now

[sbomer]

This is the right target to do the update. Once #124801 merges, I think we should remove these items from ResolvedFileToPublish instead

[sbomer]

@copilot fix merge conflict (ensure the satellite assemblies are removed from ResolvedFileToPublish).

[Copilot]

@copilot fix merge conflict (ensure the satellite assemblies are removed from ResolvedFileToPublish).

Merge conflict fixed in commit fffa5f9. Satellite assemblies are now removed from ResolvedFileToPublish on line 31 of the targets file, following the refactored approach from PR #124801.

[sbomer]

Actually it looks like the fix falls out of #124801. That's because it's removing _IlcManagedInputAssemblies from the publish set, and that appears to include satellites. Although I'm not sure if the satellite assemblies should flow through that ItemGroup in the first place - I think they get passed to ILC both as --satellite and as normal references. Maybe that could be cleaned up.

[sbomer]

I believe single-file handles this similarly and removes satellite assemblies in this line:
https://github.com/dotnet/sdk/blob/a6af77909c46799080943ee15c028462867c60f5/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Publish.targets#L1184

[sbomer]

Tested again with P3 bits and that doesn't seem to be the case, the satellite assemblies still show up. I think removing them from ResolvedFileToPublish is the proper fix (validated locally).

[Copilot]

Pull request overview

Removes redundant project satellite resource assemblies from NativeAOT publish output, aligning publish artifacts with NativeAOT behavior where satellites are embedded into the native binary.

Changes:

• Remove @(IntermediateSatelliteAssembliesWithTargetPath) entries from @(ResolvedFileToPublish) during NativeAOT publish.
• Keeps existing publish-list cleanup (managed inputs, managed PDBs) and native-binary replacement behavior intact.

[sbomer]

/ba-g "timeouts"

[nagilson]

I don't think this fix completely resolved the issue: #127086 (comment)

[MichalStrehovsky]

I don't think this fix completely resolved the issue: dotnet/runtime#127086 (comment)

We regressed that one, that one used to work. In my comment above (#124192 (comment)) I'm asking copilot about where are we dropping satellite assemblies from references because those I was certain we did drop already at that time.

I just double checked with a simple Console.WriteLine(typeof(System.CommandLine.RootCommand)); with <PackageReference Include="System.CommandLine" Version="2.0.6" /> (because I know System.CommandLine has satellite assemblies). .NET 11 Preview 2 drops them. With .NET 11 Preview 3 we keep them :(.

[baronfel]

@MichalStrehovsky should we open an issue on runtime to track? Or do you think the answer is on our side?

[sbomer]

Taking a look - I suspect the issue is on the runtime side. I moved that issue over to track.