测试.NET Core 3.1 AWS Lambda时遇依赖程序集缺失错误求助

我之前在做AWS Lambda结合EF Core的项目时，也遇到过类似的本地测试工具依赖问题，给你整理几个可行的解决方向：

1. 检查项目运行时配置与发布设置 #

• 首先确认你的项目.csproj文件里是否正确设置了RuntimeIdentifier（RID）。报错里提到的是win-x64，你可以显式添加配置确保输出对应平台的依赖：

  <PropertyGroup>
    <RuntimeIdentifier>win-x64</RuntimeIdentifier>
    <!-- 如果需要兼容Lambda的Linux环境，也可以多RID配置 -->
    <!-- <RuntimeIdentifiers>win-x64;linux-x64</RuntimeIdentifiers> -->
  </PropertyGroup>
  

• 检查是否启用了程序集裁剪：如果设置了<PublishTrimmed>true</PublishTrimmed>，可能会误删掉native依赖库，建议暂时改成false再重新构建测试。
• 添加<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>到PropertyGroup，强制把所有依赖（包括native库）复制到输出目录。

2. 清理依赖缓存并重建项目 #

有时候旧的NuGet缓存或bin/obj目录残留会导致依赖混乱，执行以下步骤：

• 清理NuGet本地缓存：在终端运行 dotnet nuget locals all --clear
• 手动删除项目根目录下的bin和obj文件夹
• 重新执行dotnet restore和dotnet build命令

3. 显式指定System.Data.SqlClient版本 #

EF Core 3.x可能会间接依赖旧版本的System.Data.SqlClient，你可以显式引用一个稳定的新版本来覆盖依赖链：
在.csproj里添加：

<PackageReference Include="System.Data.SqlClient" Version="4.8.5" />

这个版本包含了完整的win-x64 native库，加上之前的<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>设置，应该能确保sni.dll被复制到输出目录。

4. 排查依赖清单文件 #

打开项目输出目录下的TestLambda.deps.json，搜索runtime.win-x64.runtime.native.System.Data.SqlClient.sni，看看这个依赖是被哪个包间接引入的（比如可能是Microsoft.EntityFrameworkCore.SqlServer）。找到根源后，可以尝试更新那个包的版本，解决依赖版本冲突问题。

5. 检查AWS Lambda Test Tool版本兼容性 #

你当前使用的测试工具版本是0.10.1，这个版本和.NET Core 3.1可能存在兼容性问题。可以尝试：

• 升级到.NET Core 3.1对应的最新测试工具版本（注意.NET Core 3.1已进入维护期，选择对应分支的稳定版）
• 如果升级后还是有问题，也可以尝试降级到更早期的稳定版本测试

6. 验证真实Lambda环境 #

有时候本地测试工具的环境和AWS Lambda的Linux环境差异较大，可以尝试直接部署到Lambda进行测试。如果部署后运行正常，说明问题可能仅存在于本地测试工具的配置中，你可以暂时跳过本地测试，或者继续排查测试工具的环境配置。

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