.NET Core 2.2自包含部署Ubuntu后EF Core查询翻译异常

你遇到的这个问题挺典型的——跨平台发布.NET Core自包含应用时，EF Core的SQL查询翻译行为不一致，核心原因大概率是依赖版本不匹配或者跨编译时的组件打包问题，下面分点给你拆解和解决思路：

1. 优先排查Pomelo.EntityFrameworkCore.MySql版本一致性 #

你提到在Ubuntu服务器本地拉取代码构建后运行正常，但Windows上交叉编译发布的包就出问题，这很可能是两边的NuGet依赖版本不一样导致的：

• Windows开发机的NuGet缓存里的Pomelo版本，和Ubuntu服务器上还原的版本可能存在细微差异（比如补丁版本），而不同版本的Pomelo对EF Core查询翻译的处理逻辑有区别。
• 解决办法：
  • 打开你的项目文件（.csproj），明确指定Pomelo包的版本，比如：

    <PackageReference Include="Pomelo.EntityFrameworkCore.MySql" Version="2.2.6" />
    

  • 清理本地NuGet缓存，避免旧版本干扰：

    dotnet nuget locals all --clear
    

  • 重新执行dotnet restore、dotnet build和dotnet publish命令。

2. 自包含跨编译的组件打包问题 #

在Windows上为Ubuntu环境构建自包含应用时，.NET Core SDK可能没有正确打包针对Linux环境的EF Core提供程序原生组件，导致运行时EF Core无法正确识别MySQL的SQL语法，进而无法将OrderByDescending翻译为SQL，只能本地评估。

• 解决办法：
  • 最稳妥的方式是直接在Ubuntu服务器上完成发布流程：拉取代码后，在服务器上执行dotnet restore、dotnet build、dotnet publish命令，这样依赖会直接针对Ubuntu环境打包，避免跨编译带来的兼容性问题。
  • 如果必须在Windows上交叉编译，确保你的项目文件中声明了支持的运行时标识：

    <PropertyGroup>
      <RuntimeIdentifiers>ubuntu.18.04-x64;win10-x64</RuntimeIdentifiers>
    </PropertyGroup>
    

    然后重新执行发布命令，确保SDK正确加载对应运行时的依赖。

3. 检查EF Core上下文的配置差异 #

生产环境的日志显示Entity Framework Core 2.2.6-servicing-10079 initialized 'ApplicationDbContext' using provider 'Pomelo.EntityFrameworkCore.MySql' with options: None，这里的options: None意味着你的DbContext可能没有配置额外的查询相关选项，不过开发环境可能隐含了一些配置？

• 解决办法：
  • 检查ApplicationDbContext的配置代码，确保生产环境和开发环境使用相同的配置，比如没有在开发环境中额外启用查询翻译的兼容选项。
  • 可以尝试在配置DbContext时显式指定MySQL的版本，比如：

    options.UseMySql(connectionString, mysqlOptions => mysqlOptions.ServerVersion(new Version(5, 7, 30), ServerType.MySql));
    

    明确服务器版本有助于Pomelo生成更匹配的SQL。

4. 验证SQL常量的一致性 #

虽然概率较低，但可以确认一下Sql.GetSuggestions这个常量在不同环境下的值是否一致，比如有没有条件编译导致Windows和Linux下的SQL字符串不同（比如换行符、空格差异），不过你提到服务器本地构建正常，这个可能性不大，但可以快速排查一下。

内容的提问来源于stack exchange，提问作者petko