在与开发区域设置不同的区域设置中部署应用程序
我的.Net .exe 用于读取文件并将信息存储在sql DB 中。 在开发系统上，我们有美国语言环境的默认设置和文件，并且一切正常。
我使用相同的 .exe 并部署到我们的 Prod 服务器，其中默认设置和文件位于英国区域设置。
我使用了 Datetime.Parse ，它应该以本地系统的格式解析日期，即美国 MM/dd/yyyy 和英国 dd/MM/yyyy。
但是，在解析英国格式的日期时，它给出了一个例外，有人可以帮我解决我哪里做错了吗？
我还注意到一些奇怪的事情，当我将开发机器的默认设置更改为 UK，然后编译 .exe 并部署相同的文件时，它就可以工作了。
您也可以让我知道为什么它有效吗？
My .Net .exe is used to read a file and store information in sql DB.
On the dev system we had default setting and files in US locale and things were working fine.
I used the same .exe and deployed on to our Prod server where the default setting and files are in UK locale.
I have used the Datetime.Parse which should be parsing the date in the format of local system i.e for US MM/dd/yyyy and for UK dd/MM/yyyy.
But while parsing the date in UK format it gives an exception, Can someone help me out where am I doing wrong.
I also noticed something strange that when I changed the default setting of dev machine to UK and then compiled the .exe and deployed the same it worked.
Can you also let me know why did it worked.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您必须向 DateTime.Parse() 方法提供 iformatprovider （即 System.Globalization.CultureInfo 的实例）。 顺便说一句，我建议使用 TryParse，或者如果您确切知道日期时间字符串如何到达，请使用 TryParseExact，因为它们要快得多。
you have to supply an iformatprovider (i.e. an instance of a System.Globalization.CultureInfo) to your DateTime.Parse() method. btw, i suggest using TryParse or if you exactly know how your datetime strings arrive, use TryParseExact as they are much faster.
最好的解决方案是在 app.config 中指定区域设置，覆盖机器的区域设置。
The best solution is to specify the locale in the app.config, overriding the machine's.
如果没有更多详细信息，很难说，但也许应用程序服务器和 sql 服务器运行的语言设置与您预期的不同。 即使应用程序服务器上的区域性设置正确，sql 服务器上的日期时间格式仍然不符合预期。
Hard to say without more details, but maybe the application server and the sql server ran on another language setting than you expected. Even when you got the culture setting on the application server right, the date time formats on the sql server still are not as expected.