[Breaking change]: MSBuild will now Respect DOTNET_CLI_UI_LANGUAGE

[nagilson]

Description

Before. if DOTNET_CLI_UI_LANGUAGE was set, if you ran a command such as dotnet build, the messages coming from the .NET SDK code would be in the language set to DOTNET_CLI_UI_LANGUAGE (example: ja for Japanese). BUT the messages from MSBuild code would still be in english.

Version

.NET 8 Preview 5

Previous behavior

MSBuild output would always be in english and use its own encoding for english regardless of DOTNET_CLI_UI_LANGUAGE.

New behavior

MSBuild output will be in UTF8 encoding now if DOTNET_CLI_UI_LANGUAGE is set on Windows and UTF 8 is supported. For all OS's, MSBuild will use the language set by DOTNET_CLI_UI_LANGUAGE instead of english.

Type of breaking change

• Binary incompatible: Existing binaries may encounter a breaking change in behavior, such as failure to load or execute, and if so, require recompilation.
• Source incompatible: When recompiled using the new SDK or component or to target the new runtime, existing source code may require source changes to compile successfully.
• Behavioral change: Existing binaries may behave differently at run time.

Reason for change

Example before:

Example after:

You can see with the current change, messages like BUILD SUCCEEDED or BUILD FAILED with information will now be in the same language as the .NET SDK. This makes sense, as customers likely don't want a mix of different languages for some of their dotnet output if they said for it to be one particular language.

Recommended action

If you would like to keep the old behavior, unset DOTNET_CLI_UI_LANGUAGE via set DOTNET_CLI_UI_LANGUAGE= in the CMD or a respective command for your shell to change environment variables. You may also disable the MSBuild Change Wave of Wave17_8 if you want to keep the .NET SDK using the language but not msbuild: https://learn.microsoft.com/en-us/visualstudio/msbuild/change-waves?view=vs-2022

Note that this should be added to the change waves document listed above.

Feature area

Other (please put exact area in description textbox)

Affected APIs

Feature Area: MSBuild (& .NET SDK)

---

Associated WorkItem - 97020

[nagilson]

cc @rainersigwald @Forgind @JanKrivanek

[rainersigwald]

The change doc should make clear that this applies to MSBuild.exe as well as dotnet build/dotnet msbuild scenarios.

No need to mention the change wave--that's an emergency thing; if someone needs it we want them to file a bug about the problem so we can fix it. (We should still put it in the change wave docs though)

For all OS's, MSBuild will use the language set by DOTNET_CLI_UI_LANGUAGE instead of english.

Instead of the operating system's language, right?

[nagilson]

That all sounds right to me!

[gewarren]

@ghogen Is it on your radar to update https://learn.microsoft.com/en-us/visualstudio/msbuild/change-waves?view=vs-2022?

[Forgind]

@ghogen Is it on your radar to update https://learn.microsoft.com/en-us/visualstudio/msbuild/change-waves?view=vs-2022?

The person who makes the PR normally does this; I asked nagilson to take care of it.

[Forgind]

(That list comes from https://github.com/dotnet/msbuild/blob/main/documentation/wiki/ChangeWaves.md, though it's a little out-of-date.)

[gewarren]

I set my language to fr-ca and I'm seeing everything in French, even though I'm not using .NET 8 Preview 5. Why is that?

[nagilson]

@gewarren That's a very good question and is surprising to me. Thanks for bringing it up.

How did you set the language? Is the OS language set anywhere?

If that's the case then the previous behavior in msbuild would pick it up. This is for if the cli environment variable is set to something other than both the os language and os culture. You may need to start a new terminal to get the old behavior as well if you've ran the newer stuff on it.

[gewarren]

@nagilson My OS language is set to English and OS region is United States. This is how I set the CLI language:

set DOTNET_CLI_UI_LANGUAGE=fr-ca

[nagilson]

Hm. I need to take some time to look into this and get back to you.

There was some logic in-place for this but it was not comprehensive and never accounted for the environment variable, so off-hand I don't know why it might work in some cases on older versions

[nagilson]

I tried using the same version of MSBuild but it didn't work for me:

I discovered it seems this is 'fixed' by the change I made in the SDK in 7.0.300 we worked on here: #34250
But for this version MSBuild isn't technically aware of the environment variable: it's because the SDK has temporarily changed the console culture. @gewarren I would suggest marking this as fixed in the sdk in 7.0.300 but in msbuild separately by the v17.7.0 version of msbuild and .net 8 preview 5 version of the sdk. Awkwardly, MSBuild doesn't use the same versioning system.

@Forgind can you think of any command where the SDK would exit before MSBuild finishes? I didn't see any commands like that, for build it waits until the msbuild proc is finished. But if there are any such commands, there would be a race condition where sometimes MSBuild versions older than the one that went into 8.0 preview 5 would still use english. This fixes that.

What this change does do is make MSBuild pick up the language by itself or regardless of the .NET SDK that it's in. So the real change is if you invoke MSBuild without that fix in the 7.0.300 SDK or outside of the .NET SDK, it will still respect the environment variable.

[nagilson]

It also appears that in 'half-fixed' version in 7.0.300, and with 7.0.200, this issue where MSBuild is in english but .NET is not appears to happen on the first run, but is corrected after that:

With the new change in 8 preview 5, it works for the first time on a clean machine.