Ensure that Trimming and AOT scenarios trigger downloading of necessary runtime packs #51765

baronfel · 2025-11-15T19:10:31Z

Fixes #51667, #51766, #50093 and likely many others.

There was a gap when restoring a project for a RID and then publishing it for that same RID with --no-restore where if that project only set PublishTrimmed or PublishAOT, the runtime packs for that RID would not be restored. This would lead to the publish command failing saying that required runtime packs weren't available. There were a couple workarounds:

explicitly specify all RuntimeIdentifiers that you would like the project to Publish for
- this causes Restore to correctly download all of the packs for the various RIDs up-front based on the publishing modality you choose
add PublishSelfContained or SelfContained to the project
- this would trigger the existing 'if self contained then get the right runtime packs' behavior that we wanted in the first place

Along the way I added some tests to cover the new scenarios, and extracted out a documentation spec to capture how we think ProcessFrameworkReferences should behave, modulo any bugs. In the future we should be able to reference this when answering questions about what the expected behavior is.

I also made a tasks.slnf to make it easier to iterate on the SDK's MSBuild Tasks and their tests in isolation. This massively helps the VSCode user experiences, especially on the testing inner loop.

…in VSCode

…also bring in the runtime packs when targeting a single RID. This fixes a gap where 'dotnet restore' for a RID followed by 'dotnet publish --no-restore' for that RID in trimming/AOT scenarios wouldn't work.

baronfel · 2025-11-15T19:12:59Z

test/Microsoft.NET.TestFramework/Microsoft.NET.TestFramework.csproj

+   <ItemGroup>
+    <ProjectCapability Remove="TestContainer" />
+  </ItemGroup>


Oh, this is a bugfix from the DevKit folks (thanks @peterwald!) that unblocks the DevKit test explorer experience.

Because this project references xunit (thanks Arcade!) the xunit package adds this capability. Because the project has this capability, DevKit tries to load it as a test. Because this project is a library and doesn't have all of the test dependencies, it fails to load and crashes the test-discovery process.

Copilot

Pull Request Overview

This pull request fixes a gap in runtime pack resolution where projects using PublishTrimmed or PublishAot without SelfContained=true would fail during publish with --no-restore because required runtime packs weren't downloaded during restore.

Key Changes:

Introduced DeploymentModelRequiresRuntimeComponents property that consolidates logic for determining when runtime packs are needed, now including RequiresILLinkPack (set when trimming is enabled) alongside SelfContained, ReadyToRunEnabled, and PublishAot
Refactored KnownRuntimePack struct to use C# 12 primary constructor and readonly properties for better maintainability
Added comprehensive unit tests covering various publish scenarios including trimming and AOT without self-contained deployment
Created documentation specification detailing expected behavior of ProcessFrameworkReferences task across different deployment scenarios

Reviewed Changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
src/Tasks/Microsoft.NET.Build.Tasks/ProcessFrameworkReferences.cs	Core fix to runtime pack resolution logic; refactored struct to use modern C# features; introduced constants and helper properties for better code clarity
src/Tasks/Microsoft.NET.Build.Tasks.UnitTests/ProcessFrameworkReferencesTests.cs	Added comprehensive test coverage for PublishTrimmed, PublishAot, and ReadyToRun scenarios with and without SelfContained; added support for ReadyToRunEnabled in test configuration
documentation/specs/ProcessFrameworkReferences-outputs.md	New specification document describing expected outputs for different deployment scenarios and documenting the fix for issue #51667
test/Microsoft.NET.TestFramework/Microsoft.NET.TestFramework.csproj	Removed TestContainer project capability to prevent VS from treating the framework project as a test container
tasks.slnf	New solution filter for convenient development focused on build tasks projects

src/Tasks/Microsoft.NET.Build.Tasks/ProcessFrameworkReferences.cs

documentation/specs/ProcessFrameworkReferences-outputs.md

Co-authored-by: Copilot <[email protected]>

baronfel · 2025-11-15T23:08:29Z

src/Tasks/Microsoft.NET.Build.Tasks/ProcessFrameworkReferences.cs

+        /// <summary>
+        /// We have several deployment models that require the use of runtime assets of various kinds.
+        /// This member helps identify when any of those models are in use, because we've had bugs in the past
+        /// where we didn't properly account for all of them.
+        /// </summary>
+        private bool DeploymentModelRequiresRuntimeComponents =>
+            SelfContained || ReadyToRunEnabled || PublishAot || RequiresILLinkPack;


This member is the actual fix. Every other change is tests, infra, debugging utility, clarity, etc.

baronfel · 2025-11-15T23:30:39Z

I'll need to add some more tests covering the end-to-end, because while this change does cause ProcessFrameworkReferences to correctly include the relevant runtime packs for Trimmed-and-up scenarios:

the subsequent behavior of the ILLink targets implies that the SelfContained property itself needs to be set. There's a bit of circularity here because those targets get produced from the runtime. I think we don't want to continue to increase our reliance on SelfContained directly. I suspect this behavior of SelfContained in the ProcessFrameworkReferences Task is the reason for our over-reliance on both it and the _IsPublishing mechanism. Adding the following Target to my test project to 'patch up' the behavior of the ILLink targets to support a more broad concept of 'is this project using one of the self-contained modalities' made the publish compile as expected:

	<Target Name="PatchSelfContainedForILLinkSupport" BeforeTargets="PrepareForILLink">
		<PropertyGroup>
			<SelfContained Condition="'$(SelfContained)' == '' and (
				'$(PublishSelfContained)' == 'true' or
				'$(PublishTrimmed)' == 'true' or
				'$(PublishAOT)' == 'true'
			)">true</SelfContained>
		</PropertyGroup>
	</Target>

I strongly suspect that if we expanded this check in the ILLink Targets:

   <Target Name="PrepareForILLink"
           DependsOnTargets="_ComputeManagedAssemblyToLink">
     ... 
    <!-- The defaults currently root non-framework assemblies, which
         is a no-op for portable apps. If we later support more ways
         to customize the behavior we can allow linking portable apps
         in some cases. -->
    <NETSdkError Condition="'$(SelfContained)' != 'true'" ResourceName="ILLinkNotSupportedError" />
    ...
  </Target>

Then we might even be able to get away with a significant amount of _IsPublishing-related hackiness, like this in the SDK RuntimeIdentifierInference:

  <!-- Edit SelfContained to match the value of PublishSelfContained if we are publishing.
       This Won't affect t:/Publish (because of _IsPublishing), and also won't override a global SelfContained property.-->
  <PropertyGroup Condition="'$(_IsPublishing)' == 'true' and ('$(PublishSelfContained)' == 'true' or '$(PublishSelfContained)' == 'false')">
    <SelfContained>$(PublishSelfContained)</SelfContained>
  </PropertyGroup>

All of this is just being set so that the runtime packs are around.

baronfel · 2025-11-15T23:35:24Z

Nit: per #51766 (comment) PublishSelfContained doesn't trigger RuntimePack download as expected - need to cover this scenario too.

jkotas · 2025-11-16T01:23:07Z

documentation/specs/ProcessFrameworkReferences-outputs.md

+<SelfContained>true</SelfContained>
+<RuntimeIdentifier>linux-x64</RuntimeIdentifier>
+<ReadyToRunEnabled>true</ReadyToRunEnabled>
+<ReadyToRunUseCrossgen2>true</ReadyToRunUseCrossgen2>


Is there a minimum runtime pack version that the current .NET SDK is compatible with? Does the current .NET SDK still support publishing for .NET 5 in all flavors?

UseCrossgen2 property was a thing in .NET 5 where crossgen2 was in preview and setting this property to true was used to opt-in into the preview. It has no purpose (it is always true) in .NET 6+.

The SDK does still support publishing net5 apps - though you get a warning that that runtime is out of support. The property is mostly mentioned here for completeness given that it does play into the runtime pack selection in the processframeworkreferences task today - I didn't want a reader to read this and then see an entirely new concept in the implementation and wonder if we missed something critical.

The SDK does still support publishing net5 apps

Do you have a deprecation schedule for when .NET SDK is going to drop support for runtimes that are out of support for a long time?

I do not think it is a good use of resources to carry this baggage around, and the support is likely broken in number of ways anyway.

Why currently have no timeline for this. The general approach has been to allow everything, but only explicitly test 2 LTSs back. So for example net 6 is the lower bound on a lot of our tests.

If we remove testing, we have to assume that the functionality for that targeting will degrade from release to release and we're ok with that.

It's not supported today but we've held off taking any action as we didn't want to actively break customers.

What value does this provide? It builds false trust with customer that we will eventually break. In theory we could make a change and unintentionally break a "major" scenario for an EOL RID. This is saying we are ok with that. Let's be proactive in keeping the codebase clean and free of legacy baggage in support of quicker innovation.

It’s worth spelling out what the alternative looks like in these cases: users will need to download old SDKs to publish for old frameworks. I think that’s a desirable state to be in. If a customer were to ask me how they should continue building for netcoreapp3.1, knowing it is long out of support, that is what I would recommend. In the case where no testing is run and nothing is being supported, I would prioritize no changes over all else. As a netcoreapp3.1 user, no changes being made for net10 would be worth the risk.

Yes. That's the proposal. I gather this is what we're going to do. Retain the ability to acquire and build not test it.

Proposal for .NET 11 SDK:

net10.0+ -- supported

net8.0+ -- tested

net1.0+ -- mechanical enabled (will download TP and should work)

Andy is pointing out that he would not ever recommend to a customer to depend on net1.0+ mechanical enablement in .NET 11 SDK. I would do the same. It does not form a coherent story.

Sorry. I missed a key point in his first sentence. Yes, that sounds best. In any case, we agree on the proposed end point.

…n't explicitly set to true until ILLink targets are updated

baronfel · 2025-11-16T16:06:58Z

src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Publish.targets

+  <!-- The ILLink Targets expect projects to set SelfContained specifically, but the real condition they're trying to detect is
+       'does this publish scenario require runtime components'. SelfContained is just the 'legacy' signal for that.
+       See https://github.com/dotnet/sdk/pull/51765#issuecomment-3537080089 for more context.
+
+       To work around this current constraint, we can detect the scenarios where runtime components are required
+       and set SelfContained accordingly before ILLink runs. It's ok to set SelfContained this 'late' because
+       the ProcessFrameworkReferences Task (which is where runtime packs are resolved) has already run by this
+       point and it has been updated to use this 'expanded' definition of when runtime components are required
+       already (e.g. the ProcessFrameworkReferences.DeploymentModelRequiresRuntimeComponents member).
+
+       The _RequiresILLinkPack property is set based on this expanded definition, so we can reuse it as our signal here.
+       It's possible that this property is what the ILLink targets should be using directly instead of SelfContained, but
+       we may want to have more 'abstract', non-private signal.
+        -->
+  <Target Name="_AlignSelfContainedBeforeILLink" BeforeTargets="PrepareForPublish" Condition="">
+    <PropertyGroup>
+      <SelfContained Condition="'$(SelfContained)' != 'true' and '$(_RequiresILLinkPack)' == 'true'">true</SelfContained>
+    </PropertyGroup>
+  </Target>


I've added a target to the SDK that 'patches' the SelfContained status so that we can demonstrate end-to-ends - we should have a conversation on what the ILLink Targets should be conditioning on instead of SelfContained directly.

richlander · 2025-11-18T06:03:07Z

Is that dotnet/runtime issue from 2021 what you intended to link to? I do expect that the extra care you are providing them 4 years later is much appeciated.

…mptions

sbomer · 2025-11-18T18:14:35Z

src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Publish.targets


+  <!-- The ILLink Targets expect projects to set SelfContained specifically, but the real condition they're trying to detect is
+       'does this publish scenario require runtime components'. SelfContained is just the 'legacy' signal for that.
+       See https://github.com/dotnet/sdk/pull/51765#issuecomment-3537080089 for more context.


Can we update ILLink to use whatever is the non-legacy signal?

I think the comment isn't entirely accurate - the ILLink targets are trying to detect whether the publish output is self-contained since we don't support trimming individual libraries as an end-user scenario. Would PublishSelfContained be a better signal? (I'm aware that wouldn't work today because of how PublishSelfContained is implemented.)

yes - totally agree here. This entire Target should just be looked at as a 'bridge' - to see if I can get the new tests to show the 'expected'/'desired' behavior. I think it's entirely reasonable now that I have tests that I like and are green to shift this PR over to the VMR so that the ILLink condition could be updated and this target could be removed - and the tests could be run in-situ. I just don't like the experience of working directly in the VMR so I tried to push that off as long as possible :)

src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Publish.targets

baronfel · 2025-11-19T23:29:40Z

Tests are green on this - next steps are to port this over to the VMR, delete the 'bridge' Target I added here, and update the ILLink conditions I mentioned so that the whole change is applied in one go.

test/Microsoft.NET.TestFramework/Microsoft.NET.TestFramework.csproj

…sproj Co-authored-by: Michael Yanni <[email protected]>

agocke · 2025-12-06T20:03:39Z

FYI the fact that PublishSelfContained sets SelfContained is an undesirable behavior from the runtime perspective. Because SelfContained impacts both Publish and Build it causes the build to produce self-contained output when publishing for trimming/aot, which no one wants.

baronfel · 2025-12-06T20:06:31Z

FYI the fact that PublishSelfContained sets SelfContained is an undesirable behavior from the runtime perspective. Because SelfContained impacts both Publish and Build it causes the build to produce self-contained output when publishing for trimming/aot, which no one wants.

agreed - I just have a much less firm on the blast radius of making that change. I could see trying to attack it as a follow-up in the VMR after this change lands (since this change 'just' fixes the runtime-acquisition behavior for PublishTrimmed/PublishAot).

marcpopMSFT · 2025-12-08T21:05:20Z

src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Publish.targets

+       not by the user.
+  -->
+  <Target Name="_AlignSelfContainedBeforeILLink" BeforeTargets="PrepareForPublish" Condition="'$(_SelfContainedWasSpecified)' != 'true' and '$(SelfContained)' == 'false' and '$(_RequiresILLinkPack)' == 'true'">
+    <PropertyGroup>


Did you intentionally use RequiresILLink in process framework reference but _RrequiresILLink here?

also, could SelfContained be empty at this point?

I don't believe SelfContained can be empty at this point - the earlier logic in the RuntimeIdentifierI ference targets forces it to a Boolean as far as I can tell.

I can try to check about the naming thing - unsure as to my thought process and what the binlogs were showing at that time.

re: the naming:

_RequiresILLinkPack is the 'private' MSBuild Property that is already computed in other Targets in the Publish targets - it feeds into ProcessFrameworkReferences and is fed into the RequiresILLinkPack Task parameter - I'm not sure I've ever seen an MSBuild Task with a prefix-leading name - Task parameters are always thought of as public surface area so the distinction in name makes sense to me here.

baronfel · 2025-12-08T21:54:48Z

test/Microsoft.NET.Publish.Tests/RuntimeIdentifiersTests.cs

-        [InlineData("PublishTrimmed", false)]
-        public void SomePublishPropertiesInferSelfContained(string property, bool useFrameworkDependentDefaultTargetFramework)
+        [InlineData("PublishReadyToRun", false)] // R2R doesn't imply self-contained in 8 and above
+        [InlineData("PublishSingleFile", true)] // single-file implies self-contained


This needs updating - PublishSingleFile should not force the use of self-contained mechanisms. This was a mistake on my part. The doc in documentation/specs/ProcessFrameworkReferences-outputs.md needs to be updated, this test needs to add the PublishSingleFile/false case back in, and changes need to be applied to the ProcessFrameworkReferences Task to make it green.

EDIT: I am indeed wrong, again! The defaults for PublishSingleFile are currently set to prefer self-contained - but a user can disable the selfcontained part if they want.

baronfel added 4 commits November 14, 2025 21:08

create MSBuild-Task-specific slnf to make it easier to work on tasks …

105627d

…in VSCode

scaffold out test scenarios to demonstrate gaps

98a10bb

extract out spec for behavior of ProcessFrameworkReferences

54b4095

Update ProcessFrameworkReferences so that trimming and AOT scenarios …

6948352

…also bring in the runtime packs when targeting a single RID. This fixes a gap where 'dotnet restore' for a RID followed by 'dotnet publish --no-restore' for that RID in trimming/AOT scenarios wouldn't work.

Copilot AI review requested due to automatic review settings November 15, 2025 19:10

Copilot started reviewing on behalf of baronfel November 15, 2025 19:10 View session

baronfel commented Nov 15, 2025

View reviewed changes

Copilot finished reviewing on behalf of baronfel November 15, 2025 19:15

Copilot AI reviewed Nov 15, 2025

View reviewed changes

src/Tasks/Microsoft.NET.Build.Tasks/ProcessFrameworkReferences.cs Outdated Show resolved Hide resolved

documentation/specs/ProcessFrameworkReferences-outputs.md Outdated Show resolved Hide resolved

documentation/specs/ProcessFrameworkReferences-outputs.md Outdated Show resolved Hide resolved

baronfel and others added 3 commits November 15, 2025 13:21

Update src/Tasks/Microsoft.NET.Build.Tasks/ProcessFrameworkReferences.cs

dcd5bbc

Co-authored-by: Copilot <[email protected]>

Update documentation/specs/ProcessFrameworkReferences-outputs.md

e21abc6

Co-authored-by: Copilot <[email protected]>

Update documentation/specs/ProcessFrameworkReferences-outputs.md

9e36ac1

Co-authored-by: Copilot <[email protected]>

hojmark mentioned this pull request Nov 15, 2025

Publish with --no-build --no-restore fails when using AOT in .NET 10 #51766

Open

baronfel commented Nov 15, 2025

View reviewed changes

jkotas reviewed Nov 16, 2025

View reviewed changes

patch gap in publish-for-specific-rid scenario where SelfContained is…

eb417d3

…n't explicitly set to true until ILLink targets are updated

baronfel requested review from a team as code owners November 16, 2025 16:06

baronfel commented Nov 16, 2025

View reviewed changes

This was referenced Nov 16, 2025

Template engine tests hitting known parallelism issue in GetVisualStudioInstances #44878

Open

Could Not Resolve SDK - repo testfx issue #51530

Open

baronfel added 2 commits November 17, 2025 17:01

fix some tests by updating expectations for the new world

2b031cd

reduce the blast-radius of the selfcontained-assignment

7c185c5

build-analysis bot mentioned this pull request Nov 18, 2025

arcade/src/Microsoft.DotNet.Arcade.Sdk/src/DownloadFile.cs:line 184 TimeoutException: The operation was canceled. dotnet/dnceng#6074

Open

3 tasks

make the SelfContained-fixup task correctly override earlier SDK assu…

8ae83d8

…mptions

sbomer reviewed Nov 18, 2025

View reviewed changes

build-analysis bot mentioned this pull request Nov 18, 2025

slow macOS - "##[error]The job running on agent Azure Pipelines 9 ran longer than the maximum time of 60 minutes." dotnet/dnceng#1883

Open

3 tasks

remove obsolete tests

a2a3ebc

MiYanni approved these changes Nov 25, 2025

View reviewed changes

test/Microsoft.NET.TestFramework/Microsoft.NET.TestFramework.csproj Outdated Show resolved Hide resolved

Update test/Microsoft.NET.TestFramework/Microsoft.NET.TestFramework.c…

d20d7f9

…sproj Co-authored-by: Michael Yanni <[email protected]>

baronfel added DO NOT MERGE PublishVsBuild Area-NativeAOT Native AOT compilation Area-Trimming labels Nov 25, 2025

jkotas mentioned this pull request Dec 1, 2025

Consider: drop mono support for .NET Framework apps #51953

Open

marcpopMSFT reviewed Dec 8, 2025

View reviewed changes

baronfel commented Dec 8, 2025

View reviewed changes

baronfel mentioned this pull request Dec 8, 2025

create a tasks-focused solution filter, and make repo tests more usable in VSCode #52072

Merged

minimize diffs

2187cf0

Copilot AI mentioned this pull request Dec 9, 2025

[WIP] Remove mono support for .NET Framework applications #52091

Draft

8 tasks

Ensure that Trimming and AOT scenarios trigger downloading of necessary runtime packs #51765

Are you sure you want to change the base?

Ensure that Trimming and AOT scenarios trigger downloading of necessary runtime packs #51765

Uh oh!

Conversation

baronfel commented Nov 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Reviewed Changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

baronfel commented Nov 15, 2025

Uh oh!

baronfel commented Nov 15, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

richlander Dec 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

richlander commented Nov 18, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

baronfel Nov 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

baronfel commented Nov 19, 2025

Uh oh!

Uh oh!

agocke commented Dec 6, 2025

Uh oh!

baronfel commented Dec 6, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

baronfel Dec 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

baronfel commented Nov 15, 2025 •

edited

Loading

richlander Dec 6, 2025 •

edited

Loading

baronfel Nov 18, 2025 •

edited

Loading

baronfel Dec 8, 2025 •

edited

Loading