When RuntimeIdentifier is specified on executable application project, compiler shouldn't copy not used native libraries to output directory

[AlexeiScherbakov]

Describe the bug

1. Executable application project or test project with <RuntimeIdentifiers>win-x64</RuntimeIdentifiers>, which references libraries with native dependencies
2. All native dependencies a copied to output dir. Even exotic like linux-musl-loongarch64

To Reproduce

Small example. Console windows x64 only app with Magick.Net. Magick.Net dependency for Windows x64 is about 23Mb. Compiler copies 230Mb (linux, osx, etc).

Project file

<Project Sdk="Microsoft.NET.Sdk">

	<PropertyGroup>
		<OutputType>Exe</OutputType>
		<TargetFramework>net10.0</TargetFramework>
		<ImplicitUsings>enable</ImplicitUsings>
		<Nullable>enable</Nullable>
		<RuntimeIdentifiers>win-x64</RuntimeIdentifiers>
	</PropertyGroup>

	<ItemGroup>
		<PackageReference Include="Magick.NET-Q8-AnyCPU" Version="14.13.0" />
	</ItemGroup>

</Project>

Program.cs

var type = typeof(ImageMagick.MagickImage);
Console.WriteLine("{0}", type.FullName);

Further technical details

details of dotnet --info

 Version:           10.0.102
 Commit:            4452502459
 Workload version:  10.0.100-manifests.6d969a7e
 MSBuild version:   18.0.7+445250245

• The IDE is VS 2026

[baronfel]

I believe you're asking for this feature: #53140

In general, we don't have a publish story for projects that set RuntimeIdentifiers - we don't iterate per-RID and do an 'inner' publish the way we do for container builds or .NET Tools. As a result, a publish of an executable project today behaves in a 'framework-dependent' mode - it bundles all of its dependencies because it can run on any platform. With #53140 we want to give you a knob to control that more explicitly for these framework-dependent apps.

Now, there are inconsistencies here. Weirdly, we do default Exe-type projects to an 'apphost' - a platform-specific executable. Usually when we do something that implies platform-specificity like this, we do it by implicitly setting a RuntimeIdentifier - but we're not doing that here and so the per-RID filtering that you'd expect to happen doesn't. @dsplaisted I'd love to chat through the implications here.

[AlexeiScherbakov]

Yes, I found it strange because nuget packages are located in central repo in developer computer and native assets are always accessible for deploy .
When dev starting application in Visual Studio on Windows it is very weird that SDK copy to output directory files which application or test project will never use in all situations. Then I found property RuntimeIdentifiers and it simply do nothing :-)