-
Notifications
You must be signed in to change notification settings - Fork 281
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Detecting globalization-invariant mode fails #1913
Labels
🙌 Up-for-Grabs
Anyone interested in working on it can ask to be assigned
Comments
Hi @jeroen-mostert , thanks for bringing this issue to our attention and providing the repro steps. We'll see what we can do and we'll get back to you soon. |
This is by design as you mentioned in #81. |
Reopening. We should fix the behavior to return the previous (clearer) error message. Not a high priority, though. |
David-Engel
added
🙌 Up-for-Grabs
Anyone interested in working on it can ask to be assigned
and removed
By Design
By design
labels
Jan 31, 2023
This was referenced May 11, 2023
.net 8 will set |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
As part of fixing #81 (late failure on detecting globalization-invariant mode), code was added to detect this situation early and give a descriptive error. Unfortunately this code (which uses
CultureInfo.GetCulture("en-US").EnglishName
) is broken from .NET 6 onward, as a result of this breaking change which makes asking for specific cultures a runtime error. As a result, attempting to open a connection in globalization-invariant mode now produces this message instead:This is still better than nothing as it fails early and points the user in the right direction, but not as clear as it could be and potentially confusing if the user isn't actually using the
en-US
culture at all.To reproduce
.csproj:
Main.cs:
Expected behavior
Ideally the output should be what it was when targeting
netcoreapp31
or earlier:Additional context
There appears to be no public API in the CLR for detecting this mode -- something which has bitten other library authors as well, e.g. this SO issue. The proposed workarounds include a lot of code for what should conceptually be a simple check, so it may be worth petitioning the core team with an API proposal and leaving this issue until that's sorted. This has been done at runtime#81429.
The text was updated successfully, but these errors were encountered: