Allow culture to be configured project-wide

[JochCool]

Many, many developers are not aware that the behaviour of ToString() varies from device to device, because it depends on the configured culture. This leads to one of the most common and most subtle bugs in .NET applications being the wrong culture being used for string conversions. It annoys me every time I see a comma being used as decimal separator instead of a dot, in the middle of normal English text.

The code analysis rule CA1305 helps with finding many (but not all) of these bugs, but most developers do not know about it as it is not enabled by default. But even then, fixing it is a pain, because it always makes your code more verbose. Every single string interpolation needs to be changed from $"Example {i}" to string.Create(CultureInfo.InvariantCulture, $"Example {i}"). No developer wants to waste their time on this.

Another possible solution is to simply change the default by setting Thread.CurrentThread.CurrentCulture = CultureInfo.InvariantCulture; – but then don't forget to also update CultureInfo.DefaultThreadCurrentCulture, and while you're at it also Thread.CurrentThread.CurrentUICulture and CultureInfo.DefaultThreadCurrentUICulture. You then also have to put this at the start of every project and every unit test. Again, no one can be bothered. Besides, this is not an option if you're making a public library (e.g. to implement a certain standard), or if you're using a framework that generates the Main for you so that you can't put anything at the start of your program.

And sure, might be cases where you do want your string conversions to be dependent on the system's culture, which is something that needs to remain supported (even though I have not encountered such projects). But at least we need to be able to configure the default culture project-wide. And preferably, the default is set to the invariant culture for new projects (just like how nullable context and implicit usings are turned on by default in new projecs). For existing projects, all you'll have to do is edit the .csproj file and all your bugs are fixed.

[chrisoverzero]

For the specific case of the invariant culture, an invariant mode has been available since .NET Core 2.0, I think.

[JochCool]

Oh I did not know about this, thank you! This will at least help for applications that just process data and don't display user-facing text.

[HaloFour]

This feels like it would be a runtime request as the language itself is culture agnostic and some kind of project flag would have to be compiled down into something that the runtime would understand in order to affect the behavior of all of these different APIs.

And sure, might be cases where you do want your string conversions to be dependent on the system's culture, which is something that needs to remain supported (even though I have not encountered such projects).

I'd think that would always be the default for desktop applications, as you'd expect the UX to operate in the user's culture.

[jaredpar]

Closing as this really isn't a C# language request but more of a .NET runtime one. I encourage you to file this issue on dotnet/runtime.

[JochCool]

Thanks. I thought this was the appropriate place because adding a project property would still involve the compiler, but I guess that's an MSBuild thing and not a C# thing?