[ASP.NET 5]终于解决:Unable to load DLL 'api-ms-win-core-localization-obsolete-l1-2-0.dll'

11月12日,惊喜地发现SqlClient(System.Data.SqlClient.dll)跨平台了(对应的nuget包包是runtime.unix.System.Data.SqlClient),终于可以在Linux上基于.NET Core运行ASP.NET 5程序访问SQL Server数据库了。

于是,立马更新dnx至rc2,用之前已经写好的、用EF7访问SQL Server数据库的ASP.NET 5示例程序,分别在2台Linux服务器上进行测试。但测试时遇到了一个非常奇怪的问题:其中1台Linux服务器上可以正常访问SQL Server数据库,而另外1台Linux服务器上运行时总是出现这样的错误:

DllNotFoundException: Unable to load DLL 'api-ms-win-core-localization-obsolete-l1-2-0.dll': The specified module could not be found.
(Exception from HRESULT: 0x8007007E)
System.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, UInt32 waitForMultipleObjectsTimeout, Boolean allowCreate, Boolean onlyOneCheckConnection, DbConnectionOptions userOptions, DbConnectionInternal& connection)

这2台Linux服务器分别访问的是2台不同的SQL Server,能正常访问的服务器用的是自己在纯英文操作系统上安装的SQL Server,不能正常访问的服务器用的是阿里云RDS。

当时以为是这2台Linux服务器的系统环境不一样引起的,于是分别重装操作系统,重新安装dnx,问题依旧。。。折腾了几天,实在找不出原因,就将问题放之一边。

今天(11月19日),微软正式发布了ASP.NET 5 RC1,于是又基于ASP.NET 5 RC1测试了一下,问题还是依旧。

但是今天在测试时,进行了一个之前遗漏的测试,在出问题的服务器上访问不出问题的服务器所用的SQL Server,结果问题立马消失。

太奇怪了!怎么会与SQL Server有关?于是将阿里云RDS换成了另外1台自己安装的SQL Server,但也是同样的问题。现在问题变成了:同样的应用程序,访问1台SQL Server正常,访问另一台就出错。于是将解决问题的焦点放到了比较这2台SQL Server的不同之处,但通过SQL Profiler进行跟踪,未发现有任何不同。

后来,用EF迁移命令访问数据库:

dnx ef database update

也是同样的错误:

System.DllNotFoundException: Unable to load DLL 'api-ms-win-core-localization-obsolete-l1-2-0.dll': The specified module could not be found.
 (Exception from HRESULT: 0x8007007E)
   at System.Data.LocaleInterop.LCIDToLocaleName(UInt32 Locale, StringBuilder lpName, Int32 cchName, Int32 dwFlags)
   at System.Data.LocaleInterop.LcidToLocaleNameInternal(Int32 lcid)
   at System.Data.LocaleInterop.GetDetailsInternal(Int32 lcid)
   at System.Collections.Concurrent.ConcurrentDictionary`2.GetOrAdd(TKey key, Func`2 valueFactory)
   at System.Data.SqlClient.TdsParser.GetCodePage(SqlCollation collation, TdsParserStateObject stateObj)
   at System.Data.SqlClient.TdsParser.TryProcessEnvChange(Int32 tokenLength, TdsParserStateObject stateObj, SqlEnvChange[]& sqlEnvChange)

但是调用栈的信息不一样,当看到 TdsParser.GetCodePage 方法,突然想到是不是与Codepage有关?但是SQL Profiler看不到任何与Codepage的信息。。。

是不是漏掉了什么?是不是在SqlClient与SQL Server交互时,还有一些信息被漏掉了?得要看到它们之间的所有交互信息,怎么看呢?

看网络交互信息,最有效的方法非网络抓包莫属(所以说抓包是程序员的基本功之一)。于是在SQL Server服务器上用Wireshark抓包。。。

果然逮着了Codepage相关的东西,在SqlClient登录至SQL Server之后,SQL Server响应给客户端的内容中有这样的信息:

看!Codepage: 2052,它表示的是中文(Chinese - China),问题很可能与这里返回的Codepage有关。

但SQL Server中什么设置会影响到这里返回的Codepage值呢?搜索"windows change sql server codepage",找到了线索,原来就是Database Collation的设置。

比较了一下这2台SQL Server中对应数据库的Collation设置,没出问题的SQL Server设置的是SQL_Latin1_General_CP1_CI_AS,出问题的SQL Server设置的是Chinese_PRC_CI_AS。

于是将Collation由Chinese_PRC_CI_AS改为SQL_Latin1_General_CP1_CI_AS,问题立马解决!

当然,问题的根源不是SQL Server的Collation设置,而是跨平台的System.Data.SqlClient.dll不能正确处理Collation为Chinese_PRC_CI_AS的情况,这算是corefx中System.Data.SqlClient实现的一个bug。

不管怎么样,总算找到了问题的真正原因,暂时也有临时解决方法,在Linux服务器上基于.NET Core运行ASP.NET 5程序访问SQL Server已经成为现实。

【相关博文】

.NET跨平台之旅:升级至ASP.NET 5 RC1,Linux上访问SQL Server数据库

【更新】

该问题已被修复,详见 dotnet/corefx/pull/4958

posted @ 2015-11-19 19:09  dudu  阅读(5579)  评论(10编辑  收藏  举报