.NET 8.0 AWS Lambda引用Lambda层时程序集加载失败求助

1. 修正Lambda层的目录结构 #

AWS Lambda对.NET层的目录有严格要求，错误的结构会导致运行时无法识别依赖：

• 针对你的目标框架版本（比如.NET 6），层的ZIP包内部必须遵循lib/dotnetcoreapp<版本号>/的路径结构，所有共享库DLL直接放在这个目录下，而非lib/dotnet/shared。
  例：如果是.NET 6，ZIP包内的路径应为lib/dotnetcoreapp6.0/sharedlibrary.dll，解压后在Lambda环境中对应/opt/lib/dotnetcoreapp6.0/sharedlibrary.dll。
• 重新打包时，确保ZIP包的根目录就是lib文件夹，不要嵌套额外的目录层级。

2. 调整项目引用的正确配置 #

项目引用场景 #

修改AWSLambdaRefLayer.csproj中的项目引用节点，删除错误的<HintPath>，保留以下配置即可：

<ProjectReference Include="..\sharedlibrary\sharedlibrary.csproj">
  <Private>false</Private>
  <ExcludeAssets>all</ExcludeAssets>
</ProjectReference>

• <Private>false：确保发布Lambda项目时不会将共享库DLL打包进部署包。
• <ExcludeAssets>all：避免引入共享库的任何依赖或资源文件。

NuGet包引用场景 #

如果使用NuGet包关联共享库，需确保NuGet包版本与层中部署的DLL版本完全一致，并在引用节点中添加：

<PackageReference Include="sharedlibrary" Version="x.x.x">
  <Private>false</Private>
</PackageReference>

3. 配置Lambda环境变量（按需） #

不需要设置DOTNET_SHARED_STORE，而是添加以下环境变量确保运行时能找到层中的依赖：

• DOTNET_ADDITIONAL_DEPS=/opt/lib/dotnetcoreapp<版本号>/
  替换<版本号>为你的实际框架版本（如6.0），该变量会告诉.NET运行时额外的依赖搜索路径。

4. 发布Lambda项目的关键检查 #

• 使用dotnet publish -c Release发布后，检查输出目录（如bin/Release/net6.0/publish），确认sharedlibrary.dll未被包含在内。
• 若使用VS2022发布，在发布配置的“依赖项”设置中，确保共享库被标记为“不复制到输出目录”。

5. 排查验证步骤 #

• 在Lambda控制台查看层的内容：进入层详情页，下载层的ZIP包解压，确认DLL路径符合要求。
• 查看Lambda执行日志：日志中会包含程序集加载失败的详细路径列表，对比确认层的路径是否在搜索范围内。
• 本地模拟测试：使用AWS Lambda本地测试工具（如sam local invoke），将层内容放置在./layers/<层名称>/opt/lib/dotnetcoreapp<版本号>/，本地运行验证是否能加载依赖。

内容的提问来源于stack exchange，提问作者A.M. Patel