Ensure that Trimming and AOT scenarios trigger downloading of necessary runtime packs by baronfel · Pull Request #51765 · dotnet/sdk

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.

@baronfel xunit isn't brought by Arcade here. It's added by https://github.com/baronfel/sdk/blob/6948352a75a507040529c6eaf9a39bd6d95ac35b/test/Microsoft.NET.TestFramework/Microsoft.NET.TestFramework.csproj#L54

Instead of removing TestContainer, the project must not reference xunit in the first place. Instead, it should reference the pieces it needs from this list:

xunit.assert

xunit.extensibility.core

xunit.extensibility.execution

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.

dsplaisted · 2025-12-26T21:56:35Z

@jjonescz @baronfel There are a few test failures remaining here with dotnet run file.cs, probably because we are setting a PublishRuntimeIdentifier by default in some cases where we weren't before. I will probably need some help understanding how to handle this and whether this is a breaking change we need to fix or just a test issue.

dsplaisted · 2026-01-01T16:11:07Z

I figured out what the issue with the file run tests was. Now there are just a few failures on Linux, maybe because NatievAOT cross-compilation isn't supported there.

jjonescz · 2026-01-05T08:31:46Z

There are a few test failures remaining here with dotnet run file.cs

I figured out what the issue with the file run tests was.

@dsplaisted I'm curious what the failure was. I don't see any run-file tests failing in the build run https://dev.azure.com/dnceng-public/public/_build/results?buildId=1239391&view=ms.vss-test-web.build-test-results-tab for 1cc4b24

dsplaisted · 2026-01-05T16:28:15Z

@dsplaisted I'm curious what the failure was. I don't see any run-file tests failing in the build run https://dev.azure.com/dnceng-public/public/_build/results?buildId=1239391&view=ms.vss-test-web.build-test-results-tab for 1cc4b24

Looking back, I guess it wasn't actually a run file test that was failing, it was a single-file publish test and I misinterpreted the test name. The test was GivenThatWeWantToPublishASingleFileLibrary.ItPublishesSuccessfullyWithRIDAndPublishSingleFileLibrary.

dsplaisted · 2026-01-05T17:53:41Z

@agocke Under what OS/Architecture combinations is NativeAOT cross-publishing supported? Based on the test results, it looks like cross-architecture NativeAOT works on Windows but not Linux.

agocke · 2026-01-05T18:24:31Z

@dsplaisted There is no super-simple answer to that question. In general, cross-OS publishing is not supported. But there are exceptions. For example, publishing for Android will be supported from Windows, and publishing for iOS is supported from MacOS.

The constraint is not on our side, it is on the native toolchain side. If you have a compatible native toolchain installed, all options are supported.

agocke · 2026-01-06T19:55:37Z

@dsplaisted Docs on cross-compilation are here: https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/cross-compile

dsplaisted · 2026-01-09T16:16:43Z

/azp run

azure-pipelines · 2026-01-09T16:17:03Z

Azure Pipelines successfully started running 2 pipeline(s).

MiYanni · 2026-01-09T18:52:07Z

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

+  <PropertyGroup Condition="'$(PublishRuntimeIdentifier)' == '' And
+                            '$(RuntimeIdentifier)' == '' And
+                            '$(_IsExecutable)' == 'true' And
+                            (
+                              '$(PublishSelfContained)' == 'true' or
+                              '$(PublishReadyToRun)' == 'true' or
+                              '$(PublishTrimmed)' == 'true' or
+                              '$(PublishSingleFile)' == 'true' or
+                              '$(PublishAot)' == 'true'                                
+                            ) And
+                            !('$(PackAsTool)' == 'true' And '$(_IsPacking)' == 'true')">


This is fun. 😅

MiYanni · 2026-01-09T18:55:18Z

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

        }

-        private struct KnownRuntimePack
+        [DebuggerDisplay("{Name}@{LatestRuntimeFrameworkVersion} for {TargetFramework}")]


I've never used this attribute before. What does it do?

it's awesome - it lets you customize the way an object is rendered in the debugger only. You can still expand it to view properties, but often a quick DebuggerDisplay annotation can give you everything you need at a glance.

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

…imeIdentifierInference.targets Co-authored-by: Michael Yanni <[email protected]>

dsplaisted · 2026-01-12T12:08:03Z

/backport to release/10.0.2xx

github-actions · 2026-01-12T12:08:16Z

Started backporting to release/10.0.2xx (link to workflow run)

github-actions · 2026-01-12T12:08:46Z

@dsplaisted backporting to release/10.0.2xx failed, the patch most likely resulted in conflicts. Please backport manually!

git am output

$ git am --3way --empty=keep --ignore-whitespace --keep-non-patch changes.patch

Applying: create MSBuild-Task-specific slnf to make it easier to work on tasks in VSCode
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
No changes -- Patch already applied.
Applying: scaffold out test scenarios to demonstrate gaps
.git/rebase-apply/patch:75: trailing whitespace.
            
.git/rebase-apply/patch:77: trailing whitespace.
                "Microsoft.NETCore.App.Runtime.**RID**", 
.git/rebase-apply/patch:79: trailing whitespace.
            
.git/rebase-apply/patch:83: trailing whitespace.
            
.git/rebase-apply/patch:89: trailing whitespace.
            
warning: squelched 28 whitespace errors
warning: 33 lines add whitespace errors.
Using index info to reconstruct a base tree...
M	test/Microsoft.NET.TestFramework/Microsoft.NET.TestFramework.csproj
Falling back to patching base and 3-way merge...
Auto-merging test/Microsoft.NET.TestFramework/Microsoft.NET.TestFramework.csproj
Applying: extract out spec for behavior of ProcessFrameworkReferences
Applying: Update ProcessFrameworkReferences so that trimming and AOT scenarios also bring in the runtime packs when targeting a single RID.
Applying: Update src/Tasks/Microsoft.NET.Build.Tasks/ProcessFrameworkReferences.cs
Applying: Update documentation/specs/ProcessFrameworkReferences-outputs.md
Applying: Update documentation/specs/ProcessFrameworkReferences-outputs.md
Applying: patch gap in publish-for-specific-rid scenario where SelfContained isn't explicitly set to true until ILLink targets are updated
Applying: fix some tests by updating expectations for the new world
Using index info to reconstruct a base tree...
M	test/Microsoft.NET.TestFramework/ProjectConstruction/TestProject.cs
Falling back to patching base and 3-way merge...
Applying: reduce the blast-radius of the selfcontained-assignment
Applying: make the SelfContained-fixup task correctly override earlier SDK assumptions
Applying: remove obsolete tests
Applying: Update test/Microsoft.NET.TestFramework/Microsoft.NET.TestFramework.csproj
Using index info to reconstruct a base tree...
M	test/Microsoft.NET.TestFramework/Microsoft.NET.TestFramework.csproj
Falling back to patching base and 3-way merge...
Auto-merging test/Microsoft.NET.TestFramework/Microsoft.NET.TestFramework.csproj
CONFLICT (content): Merge conflict in test/Microsoft.NET.TestFramework/Microsoft.NET.TestFramework.csproj
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config set advice.mergeConflict false"
Patch failed at 0013 Update test/Microsoft.NET.TestFramework/Microsoft.NET.TestFramework.csproj
Error: The process '/usr/bin/git' failed with exit code 128

Link to workflow output

…alue. This adds an escape hatch (setting 'UseDefaultPublishRuntimeIdentifier=false') when trying to set a default PublishRuntimeIdentifier value. This is necessary when publishing with RuntimeIdentifiers (plural), but without a RuntimeIdentifier, which is valid when building universal apps for macOS and Mac Catalyst (the netX-macos and netX-maccatalyst target frameworks). When building such an app, the project file will set RuntimeIdentifiers (plural): <TargetFramework>net11.0-macos</TargetFramework> <RuntimeIdentifiers>osx-x64;osx-arm</RuntimeIdentifiers> and then during build/publish, the macOS SDK will run two inner builds, with RuntimeIdentifiers unset, and RuntimeIdentifier set to each of the rids (and at the end merge the result into a single app). The problem is that the outer build, where RuntimeIdentifiers is set, but RuntimeIdentifier isn't, PublishRuntimeIdentifier will now get a default value (after PR dotnet#51765), and that will set RuntimeIdentifier, which will confuse our outer build. Also note that we can't set PublishRuntimeIdentifier to the desired runtime identifiers (plural), because PublishRuntimeIdentifier is only valid for a single runtime identifier.

…alue. This adds an escape hatch (setting 'UseDefaultPublishRuntimeIdentifier=false') when trying to set a default PublishRuntimeIdentifier value. This is necessary when publishing with RuntimeIdentifiers (plural), but without a RuntimeIdentifier, which is valid when building universal apps for macOS and Mac Catalyst (the netX-macos and netX-maccatalyst target frameworks). When building such an app, the project file will set RuntimeIdentifiers (plural): <TargetFramework>net11.0-macos</TargetFramework> <RuntimeIdentifiers>osx-x64;osx-arm</RuntimeIdentifiers> and then during build/publish, the macOS SDK will run two inner builds, with RuntimeIdentifiers unset, and RuntimeIdentifier set to each of the rids (and at the end merge the result into a single app). The problem is that the outer build, where RuntimeIdentifiers is set, but RuntimeIdentifier isn't, PublishRuntimeIdentifier will now get a default value (after PR #51765), and that will set RuntimeIdentifier, which will confuse our outer build. Also note that we can't set PublishRuntimeIdentifier to the desired runtime identifiers (plural), because PublishRuntimeIdentifier is only valid for a single runtime identifier.

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

Don't default PublishRuntimeIdentifier on non-executable projects

9cca3cf

dsplaisted requested a review from a team January 9, 2026 18:44

MiYanni approved these changes Jan 9, 2026

View reviewed changes

MiYanni reviewed Jan 9, 2026

View reviewed changes

src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.RuntimeIdentifierInference.targets Outdated Show resolved Hide resolved

dsplaisted added 2 commits January 9, 2026 15:23

Fix issue detecting unsupported NativeAOT RID

bc1d06d

Don't try to test cross-architecture AOT compilation on Linux

fc02ab8

baronfel mentioned this pull request Jan 11, 2026

[draft] Implement ProcessFrameworkReferences in pure MSBuild #52396

Draft

dsplaisted removed the DO NOT MERGE label Jan 12, 2026

Update src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Runt…

941db06

…imeIdentifierInference.targets Co-authored-by: Michael Yanni <[email protected]>

dsplaisted enabled auto-merge January 12, 2026 12:08

dsplaisted mentioned this pull request Jan 12, 2026

release/10.0.2xx - Ensure that Trimming and AOT scenarios trigger downloading of necessary runtime packs #52404

Merged

dsplaisted merged commit 12e80c8 into dotnet:main Jan 12, 2026
26 checks passed

dotnet-maestro bot mentioned this pull request Jan 13, 2026

[main] Source code updates from dotnet/sdk dotnet/dotnet#3983

Closed

dsplaisted mentioned this pull request Jan 13, 2026

ProcessFrameworkReferences should add NativeAOT targeting packs for download for all passed in RIDs, not just RuntimeIdentifier #50093

Closed

dotnet-maestro bot mentioned this pull request Jan 16, 2026

[main] Source code updates from dotnet/sdk dotnet/dotnet#4241

Merged

rolfbjarne mentioned this pull request Jan 20, 2026

Add escape hatch for not setting a default PublishRuntimeIdentifier value. #52566

Merged

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!

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!

dsplaisted commented Dec 26, 2025

Uh oh!

dsplaisted commented Jan 1, 2026

Uh oh!

jjonescz commented Jan 5, 2026

Uh oh!

dsplaisted commented Jan 5, 2026

Uh oh!

dsplaisted commented Jan 5, 2026

Uh oh!

agocke commented Jan 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

agocke commented Jan 6, 2026

Uh oh!

dsplaisted commented Jan 9, 2026

Uh oh!

azure-pipelines bot commented Jan 9, 2026

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!

Uh oh!

dsplaisted commented Jan 12, 2026

Uh oh!

github-actions bot commented Jan 12, 2026

Uh oh!

github-actions bot commented Jan 12, 2026

Uh oh!

baronfel commented Nov 15, 2025 •

edited

Loading

richlander Dec 6, 2025 •

edited

Loading

agocke commented Jan 5, 2026 •

edited

Loading