Skip to content

Conversation

@dsplaisted
Copy link
Member

@dsplaisted dsplaisted commented Oct 16, 2025

Fix #51265

Description

Prevent package pruning from occurring for .NET Framework. This was supposed to have occurred with #50816, but we missed that the prune package data logic would fall back to compatible frameworks for .NET Framework, so it ended up falling back to and using the .NET Standard pruning data.

Customer impact

This will fix various problems when compiling for .NET Framework, such as

Regression

Yes

Testing

Added automated test

Have not yet been able to validate this fixes the xUnit crash

Risk

Low

acceptNearestMatch = true;
}

var frameworkPackages = FrameworkPackages.GetFrameworkPackages(nugetFramework, [frameworkReference], acceptNearestMatch)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we ever want nearest match behavior at all. Is there a scenario where we actually need it?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We were also using the nearest match as part of a workaround for dotnet/windowsdesktop#4904. That may not be needed any more but I think we should keep this change as small as possible.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we can delete in V.Next in conjunction with measuring that deleting it has zero change on all known TFMs. Just brute force and diff.

@rbhanda rbhanda added this to the 10.0.0 milestone Oct 16, 2025
@dsplaisted dsplaisted merged commit b0f6af0 into dotnet:release/10.0.1xx Oct 16, 2025
28 of 29 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants