3 ms·

As a developer or a user, you have full control over this: <InvariantGlobalization>true</InvariantGlobalization> or DOTNET_SYSTEM_GLOBALIZATION_INVARIANT

As a developer or a user, you have full control over this: <InvariantGlobalization>true</InvariantGlobalization> or DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=true (it is still an occasional gotcha, but pretty much everyone learned to be aware of it)

whizzter 1y ago
I've missed that it's possible to use as a default, thank you. Still the need to remember it is an silly cognitive load (also it seems it was introduced only with .NET Core 2, still maintaining old framework apps where this luxury doesn't seem available?).
- neonsunset 1y ago
  Historically, it was a decision to avoid cognitive load for GUI applications. To be fair, it's been a while since I've heard anyone complain about it - most servers and containers run with both an en-US locale and/or the invariant globalization set to true. It may sometimes be an issue when debugging locally but it can be quickly addressed, if the solution for some reason does not pass the culture explicitly or does not set the invariant globalization. I think before there was a global toggle it was a pretty bad default, but nowadays it's not a practical challenge at all. It's a "solved problem". As for .NET Framework applications - they have bigger issues to worry about. The teams willing/forced to stay with it know what they sign for. Also, why the downvotes?
  - whizzter 1y ago
    Yes, I agree, it's probably an inheritance of the Visual Basic roots it was supposed to take over. We got enterprise customers here in Sweden so some parts of the framework legacy are unavoidable due to that and server locale has been a bit of a crapshoot due to it being a classic on prem without fixed guidelines/needs. Also confused by the downvotes (got it on the thread-root comment also), got another "weird" downvote in another post's comment also so no idea if it's some weird bot behaviour or someone who hates me.

whizzter 1y ago

I've missed that it's possible to use as a default, thank you. Still the need to remember it is an silly cognitive load (also it seems it was introduced only with .NET Core 2, still maintaining old framework apps where this luxury doesn't seem available?).

neonsunset 1y ago
Historically, it was a decision to avoid cognitive load for GUI applications. To be fair, it's been a while since I've heard anyone complain about it - most servers and containers run with both an en-US locale and/or the invariant globalization set to true. It may sometimes be an issue when debugging locally but it can be quickly addressed, if the solution for some reason does not pass the culture explicitly or does not set the invariant globalization. I think before there was a global toggle it was a pretty bad default, but nowadays it's not a practical challenge at all. It's a "solved problem". As for .NET Framework applications - they have bigger issues to worry about. The teams willing/forced to stay with it know what they sign for. Also, why the downvotes?
- whizzter 1y ago
  Yes, I agree, it's probably an inheritance of the Visual Basic roots it was supposed to take over. We got enterprise customers here in Sweden so some parts of the framework legacy are unavoidable due to that and server locale has been a bit of a crapshoot due to it being a classic on prem without fixed guidelines/needs. Also confused by the downvotes (got it on the thread-root comment also), got another "weird" downvote in another post's comment also so no idea if it's some weird bot behaviour or someone who hates me.