Interactive Window uses Windows' regional format to localise compiler messages since VS 16.8

[LinqToException]

Version Used: Visual Studio Enterprise 16.8.2 / Interactive Compiler version 3.8.0-5.20567.16

Steps to Reproduce:

1. Install VS 16.8.x or higher
2. In Windows, set the Regional format to some non-English country, e.g. German.
3. Open a C# interactive window
4. Cause any compilation error (e.g. -;)

Expected Behavior:

The compiler error messages are in English.

Actual Behavior:

Since 16.8, the compiler messages are localized (and additionally non-ASCII characters seem to be not printed in this case):

Microsoft (R) Visual C# Interactive Compiler version 3.8.0-5.20567.16 ()
Loading context from 'CSharpInteractive.rsp'.
Type "#help" for more information.
> throw new System.ArgumentException();
System.ArgumentException: Value does not fall within the expected range.
  + <Initialize>.MoveNext()
> -;
(1,2): error CS1525: Ung�ltiger Ausdruck ";".
> ¨
(1,1): error CS1056: Unerwartetes Zeichen "�".

This is somewhat similar to #33246, except that I had never any language pack for Windows, VS or .NET installed, nor have I set German as a preferred language. It's also happening since the update to VS 16.8, which wasn't out back in February.

I've verified the behaviour by downloading VS Professional 16.7.8 on the same machine, which worked as expected. When updating it to 16.8.0, the same behaviour emerged as with Enterprise 16.8.2.

[LinqToException]

Small addendum: It make sense, but this is affecting Roslyn scripting (i.e. using CSharpScript) as well. Depending on the use case, the end user does not need to see or interpret (or cannot even be expected to) those, but the developers which end up seeing them in the logs have then to figure out what the localized messages mean. Personally, I have no clue what the localized messages are trying to tell me, as I've never read (or heard) them in their non-English counterpart.

As a workaround for that issue, deleting the local resource DLLs in both the build and the NuGet cache (%USERPROFILE%/.nuget/packages/microsoft.codeanalysis.csharp/$version$/lib/$tfm$/) has done the trick, and at least these messages are unlocalized again.

Trying the same trick, I've located the resource assemblies in the Visual Studio folder (Common7\IDE\CommonExtensions\Microsoft\ManagedLanguages\VBCSharp\LanguageServices\InteractiveHost\ and then Core or Desktop) and simply renamed/deleted the locale folders - which works like a treat. This probably won't survive an update, but it's a work around for a localized interactive window inside VS.

Edit: At least, worked until I've restarted VS, now the build fails because it can't find the files in the cache anymore. Replacing them with an empty assembly (i.e. one that does not have the necessary resources) seems to be a workaround for the workaround.

[LinqToException]

This issue is still relevant in VS 2022 17.1.6, but the path to the assemblies that need to be replaced has changed in recent VS versions. It is now Common7\IDE\CommonExtensions\Microsoft\VBCSharp\LanguageServices\InteractiveHost.

For VS 2022 community and assuming that Microsoft.CodeAnalysis.CSharp.resources.dll in the current directory is just an empty Assembly, the following Powershell is the workaround:

gci "C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\CommonExtensions\Microsoft\VBCSharp\LanguageServices\InteractiveHost\Desktop\de" | % { cp "Microsoft.CodeAnalysis.CSharp.resources.dll" $_.FullName }

If necessary, adjust the language (de) and the paths.