You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
From this StackOverflow question: The TypeManipulation code doesn't specify a culture when converting string values to other types so behavior may change based on the local machine's current culture.
The quickest fix would be to use CultureInfo.InvariantCulture everywhere - this is how ASP.NET handles parsing querystrings to ensure it's agnostic to local machine culture.
The text was updated successfully, but these errors were encountered:
Hi, is there any estimate when this could be fixed? I can't be the only one who encountered this issue as there are 150 different cultures. And not all of them uses dots as decimal separator ...
No estimate. There are only two project maintainers for core Autofac and 20+ integration libraries and we are entirely unpaid doing this in our spare time. If you'd like it fixed faster, send a PR. The fix should be to specify invariant culture where a culture is required.
…ssue autofac#26. It turned out that the invariant culture won't fix this error because is related of the implementation of the double.parse in the DoubleConverter because in the numberformatinfo the decimal separator is always a dot and they validate that is always like that. I also added some functionality as a workaround.
I believe I have a fix for this that will be coming out in Autofac.Configuration 5.0 along with Autofac 5.0 compatibility. If it still doesn't fix the issue, open a new issue and please provide a failing test that we can use to verify the fix later.
From this StackOverflow question: The
TypeManipulation
code doesn't specify a culture when converting string values to other types so behavior may change based on the local machine's current culture.The quickest fix would be to use
CultureInfo.InvariantCulture
everywhere - this is how ASP.NET handles parsing querystrings to ensure it's agnostic to local machine culture.The text was updated successfully, but these errors were encountered: