[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