Enhance invariant mode checks #1917
Conversation
Codecov ReportBase: 69.62% // Head: 69.96% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## main #1917 +/- ##
==========================================
+ Coverage 69.62% 69.96% +0.33%
==========================================
Files 292 292
Lines 61750 61759 +9
==========================================
+ Hits 42995 43209 +214
+ Misses 18755 18550 -205
Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
|
As per the discussion in runtime#81429, checking for the environment setting or app switch is not the right way of doing this -- the app may also be trimmed to not support globalization-invariant mode, and then the switches will have no effect, while this code would incorrectly detect that GIM is enabled. I think adding the exception handler is the only thing that needs to happen here. For some libraries having an unavoidable exception would be annoying, but since SqlClient is going to effectively rethrow it anyway that's not an issue. |
|
If a user specifies either the environment variable or the appcontext switch then they are expecting the app to run in invariant mode. If for some reason like trimming it doesn't run in invariant mode the intent was still that it should do, so we should still throw the error. Accidentally working because the app ignores the user can be as confusing or worse than not working. I also don't know if trimming and aot are supported scenarios for this library. There is reflection usage in the library and it isn't annotated for trimming at all. |
Whether or not the app will run in GIM based on trimming and/or switches and what the intent was is between the app and the user (and the deployer), though. It's not SqlClient's responsibility to point out they're doing something interesting by refusing to work when it could. If this is to be considered some kind of problem that should be addressed, either the app itself should check or the runtime should compile (untrimmable) code in to that effect. I can easily imagine scenarios where, for example, the environment variable is set as a default, but trimming has forced never-invariance on a particular app so it works everywhere. Is that the most elegant way of doing things? No, but why should SqlClient then refuse to play ball? The "imagine if every library did this" argument applies here.
That's another matter; even if it doesn't work today there's no real reason for this code to be a deliberate roadblock. If checking for the switch and the environment variable is not a reliable way to check for GIM, then this code shouldn't do it, because checking whether GIM is in effect is the only thing it needs (arguably even less than that, but building in full support for a limited set of cultures is a lot more involved; that's something for a future release if it's ever built at all). |
|
I have been getting this error after building a Linux images and pushing it to Kubernetes. I'm not sure what I am supposed to do in this case? Am I supposed to use the invariant environment variable or not? Also is this a case issue en-us is not en-US. Can some one please clarify what the corrective action is? Or will this all be fixed and go away in the next release? Is that out yet? Any help is appreciated as I am stuck here without a solution in sight. Thank you. |
|
You need to install the icu libraries on your container. sql server connections require the ability to create comparers which can deal with the data encoded in the database, you can't run in invariant mode. this PR only changes the checks so they report the error more cleanly on newer runtimes. |
|
I have tried that using apk with or without the invariant environment variable using the Alpine image. I am currently trying the Ubuntu Jammy image with:
RUN locale-gen en_US
RUN update-locale
Docker commands......
|
|
This did not work:
ARG VERSION=7.0-alpine3.14
#Runtime stage
FROM mcr.microsoft.com/dotnet/nightly/aspnet:$VERSION AS base
EXPOSE 5100
ENV DOTNET_RUNNING_IN_CONTAINER=true
ENV ASPNETCORE_URLS=http://+:5100
RUN apk add --no-cache icu-libs krb5-libs libgcc libintl libssl1.1 libstdc++ zlib
ENV DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=false
|
|
Using locale-gen on the Ubuntu image didn't work either. Here is my partial Dockerfile. Thank you for the help.
ARG VERSION=7.0-jammy
#Runtime stage
FROM mcr.microsoft.com/dotnet/nightly/aspnet:$VERSION AS base
EXPOSE 5100
ENV ASPNETCORE_URLS=http://+:5100
RUN locale-gen en_US
RUN update-locale
|
|
This worked at least on the Ubuntu Docker build. Hope it helps somebody else. Also this time I used a tag that didn't exist before to push to my local registry and then with that same tag deployed to Kubernetes. Not sure if there wasn't some caching going on there so maybe the Alpine code would have worked?
ARG VERSION=7.0-jammy
#Runtime stage
FROM mcr.microsoft.com/dotnet/nightly/aspnet:$VERSION AS base
EXPOSE 5100
ENV ASPNETCORE_URLS=http://+:5100
RUN apt-get update
RUN apt-get install -y locales locales-all
ENV LC_ALL en_US
ENV LANG en_US
ENV LANGUAGE en_US
|
fixes #1913
Adds checks for the appcontext switch, the environment switch and encloses the original check in a try-catch block to make it compatible with net6 which changed how invariant mode culture creation works per the information in the original thread.
/cc @jeroen-mostert