Skip to content

[release/9.0.1xx] Fix path to tool settings file in build #48877

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: release/9.0.1xx
Choose a base branch
from

Conversation

github-actions[bot]
Copy link
Contributor

@github-actions github-actions bot commented May 8, 2025

Backport of #47788 to release/9.0.1xx

Description

This change fixes a race condition/file contention bug in the .NET SDK Tools packaging targets that prevented multi-targeted Tools from successfully packaging. There's a metadata file that's created as part of the packaging process that is logically TFM-specific, but was being created/managed in a TFM-agnostic location. As a result, that file would be written to multiple times in the parallel inner-TFM packaging steps. Making this file write to a TFM-specific location makes the build race-condition-free once again.

Customer impact

The Microsoft.Extensions team publishes .NET Tools and has requested this backport so that they can remove several hacks/workarounds from their builds. We've had feedback from external users that were also impacted by this bug that the fix in the 10 nightlies fixes their builds as well.

Regression

No - this race condition was always present in the targets, people just didn't make many multi-targeted tools, or got lucky with race condition timing.

Risk

Low - we use this same RID-specific file location for a large number of other TFM-specific files during the build in other scenarios.

Testing

Manual testing during the initial fix, manual testing from internal teams and external users.

/cc @baronfel @dsplaisted

@dsplaisted
Copy link
Member

@baronfel I think the failure was more related to TargetFramework than it was to RuntimeIdentifier. Either normal multitargeted builds or multi-RID builds could have hit the issue, and the fix will fix both of them, but I think it's a lot more common for tools to multitarget over TargetFramework than RuntimeIdentifier.

@baronfel
Copy link
Member

baronfel commented May 9, 2025

@dsplaisted you're 100% right - I was going too quickly. I'll update the description.

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.

2 participants