.NET Core 3.1创建AWS Lambda层时依赖包路径不存在报错

问题根因 #

Microsoft.Extensions.DependencyInjection.Abstractions 5.0.0本身完全兼容.NET Core 3.1，报错不是包运行时兼容性导致的，是AWS Lambda .NET工具的路径匹配逻辑bug触发的
5.x版本的Microsoft.Extensions系列包的NuGet包内，lib目录下仅提供netstandard2.0的编译产物，旧版本的Amazon.Lambda.Tools在构建runtime-package-store类型层时，只会在对应netcoreapp3.1的目录下查找dll，找不到对应路径就抛出压缩失败报错。

排查步骤 #

• 首先打开本地NuGet缓存目录（默认路径为Windows：%userprofile%\.nuget\packages，macOS/Linux：~/.nuget/packages），进入microsoft.extensions.dependencyinjection.abstractions\5.0.0\lib目录，确认目录下是否只有netstandard2.0文件夹，无netcoreapp3.1文件夹
• 执行命令dotnet tool list -g查看本地安装的Amazon.Lambda.Tools版本，确认版本是否低于5.6.0

解决方法 #

方案1：降级NuGet包（最稳定） #

将包清单中的Microsoft.Extensions系列包替换为.NET Core 3.1官方配套的3.1.x版本，修改后的PackageReference如下：

<PackageReference Include="Microsoft.Extensions.DependencyInjection" Version="3.1.25" />
<PackageReference Include="Microsoft.Extensions.DependencyInjection.Abstractions" Version="3.1.25" />

3.1.x版本的包内置netcoreapp3.1目录的编译产物，完全适配旧版打包工具的路径查找逻辑。

方案2：升级Lambda打包工具（推荐） #

执行以下命令升级Amazon.Lambda.Tools到最新版本，新版本已修复跨目标框架包的路径查找问题：

dotnet tool update -g Amazon.Lambda.Tools

升级完成后重新执行原发布命令即可正常打包。

方案3：临时路径映射（仅临时测试用） #

如果不想修改包版本也不想升级工具，可以手动在报错提示的路径下创建netstandard2.0文件夹，将NuGet缓存中对应dll拷贝到该路径后重新执行发布命令，该方案为临时适配方案，不建议生产环境使用。

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