Update the logic of custom culture support by YuliiaKovalova · Pull Request #11607 · dotnet/msbuild

YuliiaKovalova · 2025-03-19T13:21:02Z

Context

This PR introduces a configurable approach to MSBuild's custom culture resource handling. It adds property EnableCustomCulture that enables custom culture resource generation and a property to exclude specific culture directories from being treated as culture-specific resources.

After this change #11000, MSBuild automatically treats directories with names that look like culture codes as culture-specific resource directories, even when they might be serving a different purpose (e.g., hash-based directories or directories with short technical names that coincidentally match a culture code). This can cause unexpected behavior in build processes and create unwanted resource assemblies.

Changes Made

A two-part approach was implemented:

Added the EnableCustomCulture project property that has to be set as true to enable custom culture resource handling.
Exclusion Property: Added the <NonCultureResourceDirectories> MSBuild property that accepts a semicolon-delimited list of directory names to exclude from custom culture processing, allowing fine-grained control.

Testing

Manual + added e2e tests.

Note

I removed unused method in test class GenerateTableWithAssemblyFromTheGlobalLocation
Update full bootstrap folder content population for windows core scenarios - add the bits from the latest local VS detected on the machine.

YuliiaKovalova · 2025-03-24T19:52:50Z

/azp run

azure-pipelines · 2025-03-24T19:53:00Z

Azure Pipelines successfully started running 1 pipeline(s).

YuliiaKovalova · 2025-03-25T10:52:23Z

bootstrap changes were validated here: #11623

JanProvaznik

overall seems reasonable, left some questions and comments

… project property

…/YuliiaKovalova/msbuild into dev/ykovalova/fix_custom_culture

Wave 17.14 is out of rotation as of MSBuild 18.10, so remove the opt-out. The only remaining live gate was SolutionFile.FullPath, which now always throws ArgumentNullException for a null or empty path. The .slnx-parser and RAR custom-culture features that originally shipped under this wave were reverted/replaced earlier (see dotnet#11607), so only stale Wave17_14 comments remained in Create{CSharp,VisualBasic}ManifestResourceName; those are cleaned up as well. Fixes dotnet#13266 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: d2ae1d52-af0e-4c11-9189-1994e36e142b

Fixes #13264 Fixes #13265 Fixes #13266 ### Context Change waves 17.10, 17.12 and 17.14 are long out of rotation, and 18.3 rotates out with them now that the repo is on 18.10. Per [ChangeWaves-Dev.md](https://github.com/dotnet/msbuild/blob/main/documentation/wiki/ChangeWaves-Dev.md#change-wave-end-of-lifespan-procedure), retiring a wave means deleting the `Version` field, removing the `AreFeaturesEnabled` conditions so the feature becomes standard behavior, dropping the tests that pinned the opted-out behavior, and cleaning up the dead code left behind. After this the rotation is 18.4 – 18.10, and the "will be removed in the release accompanying .NET 11" bucket in `ChangeWaves.md` is empty, so it is dropped. ### Changes Made One commit per wave, plus one prerequisite bootstrap fix: **`Overlay freshly-built MSBuild files into the bootstrap SDK's Current folder`** `BootstrapNetCore` overlays our build output onto the acquired SDK at `sdk\<ver>\`, but the .NET SDK layout keeps some of MSBuild's own props/targets under `sdk\<ver>\Current\`, because they are imported through `$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\...` and `$(MSBuildToolsVersion)` is `Current` there. `Microsoft.Common.props` is the notable case: in an SDK layout it exists **only** under `Current\`, and `Microsoft.NET.Sdk`'s `Sdk.props` imports it from that path for every SDK-style project. Our build output has no `Current\` subdirectory, so the overlay never replaced it. That means every bootstrap build has silently been evaluating the `Microsoft.Common.props` belonging to whatever older MSBuild the acquired SDK shipped with, and changes to `src\Tasks\Microsoft.Common.props` never took effect in bootstrap-based tests. Retiring 17.10 made that visible: the stale props still evaluated `$([MSBuild]::AreFeaturesEnabled('17.10'))`, which trips the Debug assert in `ChangeWaves` and took down 54 BuildCheck end-to-end tests. Fixing the overlay addresses the root cause and leaves the assert doing exactly the job it was added for. **`Phase out ChangeWave 17.10`** — makes unconditional: NuGet.Frameworks/AppDomain assembly loading in MSBuild.exe and VS, process-wide SDK resolver caching (`CachingSdkResolverLoader`) plus the .NET-only default-resolver fast path, target switch unquoting, `Link` metadata on `Resource` items, `-version` trailing newline, `Traits` refresh on environment change, `Exec` not trimming leading whitespace and not exporting `LANG`/`LC_ALL` on Unix, `ToolTask` console-code-page encoding, skipping project extension imports during restore, and property reassignment tracking. Also deletes `StableStringHashLegacy` and the `NoInlining` guard on `StableStringHash` that only existed to keep StringTools out of the opted-out path. **`Phase out ChangeWave 17.12`** — makes unconditional: `TaskParameterEventArgs` for scalar task parameters and output properties (the legacy textual form and `OutputPropertyLogMessage` path are gone), `InvariantCulture` for `Convert.ToString` during evaluation, `BuildRequestDataFlags` compatibility in `ResultsCache`, emitting evaluation props/items when any sink asks, `ProjectStartedEventArgs` returning empty collections instead of `null`, binlog `{}` wildcard file names, and loading `Microsoft.DotNet.MSBuildSdkResolver` into the default load context. **`Phase out ChangeWave 17.14`** — the only live gate left was `SolutionFile.FullPath`, which now always throws `ArgumentNullException` for a null/empty path. The .slnx-parser and RAR custom-culture features originally under this wave were already reverted/replaced (see #11607), so only stale `Wave17_14` comments remained in `Create{CSharp,VisualBasic}ManifestResourceName`. **`Phase out ChangeWave 18.3`** — `WriteLinesToFile` always writes atomically (temp file + replace with retry); the non-transactional path and the quarantined test asserting the old data-losing behavior are deleted. ### Testing `build.cmd -test` on Windows (net11.0 x64 + net472 x86). Everything passes except `PortableTasks_Tests.TestDesktopMSBuildShouldRunPortableTask`, which shells out to `msbuild` and fails for lack of a Visual Studio install on this machine, not because of these changes. ### Notes Behavior only changes for builds that were **opting out** via `MSBUILDDISABLEFEATURESFROMVERSION`; the default (all waves enabled) code paths make exactly the same decisions as before. Setting `MSBUILDDISABLEFEATURESFROMVERSION` to a retired wave now clamps to `18.4` and warns MSB4272, which is the documented out-of-rotation behavior. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: d2ae1d52-af0e-4c11-9189-1994e36e142b

YuliiaKovalova requested a review from rainersigwald March 19, 2025 13:22

YuliiaKovalova self-assigned this Mar 19, 2025

YuliiaKovalova force-pushed the dev/ykovalova/fix_custom_culture branch 2 times, most recently from 0d652d8 to ee7ff76 Compare March 24, 2025 17:04

YuliiaKovalova requested a review from a team as a code owner March 24, 2025 18:05

YuliiaKovalova force-pushed the dev/ykovalova/fix_custom_culture branch from 8c4fa0f to 3501934 Compare March 25, 2025 09:46

rainersigwald reviewed Mar 25, 2025

View reviewed changes

JanProvaznik reviewed Mar 25, 2025

View reviewed changes

rainersigwald reviewed Mar 25, 2025

View reviewed changes

Comment thread documentation/specs/custom-cultures.md Outdated

JanProvaznik approved these changes Mar 31, 2025

View reviewed changes

YuliiaKovalova changed the base branch from main to vs17.14 April 1, 2025 18:22

YuliiaKovalova and others added 10 commits April 1, 2025 20:46

add feature flag for custom culture

e51b29f

add test framework

a12f91b

cover the flag with tests

b768170

exclude the test from core scenarious

f4cc173

update test data

24184b6

undo extra change

0f94c2b

add bootstrap full bits population for windows core scenarious

1ab77dd

fix review comments

863babe

cleanup the description

68101ae

substitute MSBUILDENABLECUSTOMCULTURES env var -> EnableCustomCulture…

a50210f

… project property

YuliiaKovalova force-pushed the dev/ykovalova/fix_custom_culture branch from 143c564 to a50210f Compare April 1, 2025 18:47

bump the version

eaa2e60

rainersigwald approved these changes Apr 2, 2025

View reviewed changes

YuliiaKovalova added 2 commits April 2, 2025 17:58

final tweaks

b94e2fb

Merge branch 'dev/ykovalova/fix_custom_culture' of https://github.com…

ad9033e

…/YuliiaKovalova/msbuild into dev/ykovalova/fix_custom_culture

YuliiaKovalova mentioned this pull request Apr 2, 2025

[Bug]: Satellite assemblies with un-predefined cultures are not copied correctly into depended projects #10536

Closed

YuliiaKovalova enabled auto-merge (squash) April 2, 2025 16:26

YuliiaKovalova merged commit e436966 into dotnet:vs17.14 Apr 2, 2025

ibrahimhuycn mentioned this pull request Jun 19, 2026

Satellite assemblies not generated for valid neutral culture 'dv' (Divehi/Dhivehi) dotnet/sdk#54835

Open

JanProvaznik mentioned this pull request Jul 28, 2026

Phase out ChangeWaves 17.10, 17.12, 17.14 and 18.3 #14551

Merged

Uh oh!

Conversation

YuliiaKovalova commented Mar 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Context

Changes Made

Testing

Note

Uh oh!

YuliiaKovalova commented Mar 24, 2025

Uh oh!

azure-pipelines Bot commented Mar 24, 2025

Uh oh!

YuliiaKovalova commented Mar 25, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

JanProvaznik left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

YuliiaKovalova commented Mar 19, 2025 •

edited

Loading