Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

baronfel
Copy link
Member

Potential fix for dotnet/android#10500.

Historically we've included EnableDefaultItems=false in purely-evaluation or Restore scenarios as a free performance bump, since doing MSBuild glob expansion is a performance hit that isn't generally necessary in those cases.

However, we were including this flag even when running run-related Targets that in android's case involve actual building, so this assumption no longer holds. Due to this, we remove the optimization.

…ps and/or compute their run arguments we include default items

This is load-bearing for some project types, so we instead just make sure that restore-only pathways keep the old default-item exclude
@baronfel baronfel requested a review from jjonescz September 19, 2025 22:34
@baronfel baronfel changed the title make sure that when we run actual build targets to build runnnable apps Don't strip default items from build-related Targets when building runnable apps Sep 19, 2025
public static Dictionary<string, string> GetGlobalPropertiesFromArgs(MSBuildArgs msbuildArgs)
{
var globalProperties = msbuildArgs.GlobalProperties?.ToDictionary() ?? new Dictionary<string, string>(StringComparer.OrdinalIgnoreCase);
globalProperties[Constants.EnableDefaultItems] = "false"; // Disable default item globbing to improve performance
Copy link
Member

Choose a reason for hiding this comment

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

Consider adding some tests that would reproduce the issue which this is fixing.

Copy link
Member

Choose a reason for hiding this comment

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

I will probably add a test upstream in dotnet/android, I don't know how you'd reproduce the problem without the Android workload:

Copy link
Member

Choose a reason for hiding this comment

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

I think it should be fairly easy to repro in dotnet/sdk by adding <CallTarget Targets="Build" /> or something similar in a custom target that runs before/after ComputeRunArguments.

@baronfel
Copy link
Member Author

I want to get this in for RC2 and hopefully not wrestle with CI failures more than necessary, so I'll log a follow-up issue to create a test case to pin the behavior.

@baronfel baronfel merged commit 9220ac7 into dotnet:release/10.0.1xx Sep 22, 2025
26 of 27 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants