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

[baronfel]

Fixes dotnet/runtime#51667

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.

[baronfel]

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

[baronfel]

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

[baronfel]

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]

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

[jkotas]

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+.

[baronfel]

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.

[jkotas]

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.

[baronfel]

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.

[baronfel]

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.

[jkotas]

The general approach has been to allow everything

What's your confidence that the extra code required to allow everything actually works?

[baronfel]

Surprisingly high - there are a pretty high number of SDK-repo scenario tests that cover .NET 5 at least. I do get what you're saying though - there is a cost to carrying this around. There's a tension that we face on the tooling level because we want to enable folks to use the most recent tooling regardless of the TFM they're actually targeting. We feel that this is the best strategy to ensure that folks are getting the improved tooling experiences, perf improvements in the tooling, etc. The downside to this is that the tooling then needs to keep all of this downlevel logic around, and the tests contribute to overall SDK PR times, etc etc.

My gut feel is that this cost isn't incredibly high right now, but I'd be in favor of pushing tests that target these out of support or more-niche scenarios to a kind of 'outerloop' test run that doesn't block or impact normal PR flow.

[baronfel]

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.