ASP.NET Core 2.0 Web API加载AWS.SDK程序集失败问题求助

我之前也碰到过一模一样的情况，咱们来好好捋一捋这个问题的来龙去脉，以及对应的解决办法：

问题原因分析 #

ASP.NET Core 2.0的依赖解析机制和传统.NET Framework有不少区别，这里的核心问题出在NuGet依赖的传递识别上：

• 虽然项目B引用了AWS.SDK，构建时也把DLL复制到了项目A的bin/Debug/netcoreapp2.0目录里，但运行时的程序集加载上下文是基于项目的NuGet依赖图来判断的。如果项目A的依赖图里没有明确包含AWS.SDK，即使文件存在，也可能被判定为“未被正确引入的依赖”，从而抛出加载异常。
• 另外，ASP.NET Core 2.0在处理类库项目到Web API项目的依赖传递时，偶尔会出现传递依赖未被自动识别的情况，这算是那个版本的一个小坑。

可行的解决方案 #

1. 直接给项目A添加AWS.SDK的NuGet引用（你已经验证有效的办法） #

这是最直接稳妥的解决方式：

• 打开项目A的NuGet包管理器，搜索并安装和项目B中同版本的AWS.SDK包；
• 也可以手动编辑项目A的.csproj文件，添加如下配置（记得替换成实际的版本号）：

  <PackageReference Include="AWSSDK.Core" Version="你的版本号" />
  

  这样项目A的依赖图里就明确包含了AWS.SDK，运行时就能正确找到并加载它。

2. 检查项目B的依赖传递设置 #

有时候项目B的NuGet依赖被设置为不可传递，也会导致这个问题：

• 打开项目B的.csproj文件，确认AWS.SDK的引用配置是允许传递的，比如：

  <PackageReference Include="AWSSDK.Core" Version="你的版本号" PrivateAssets="none" />
  

  PrivateAssets="none"表示这个依赖可以传递给引用项目B的其他项目（也就是项目A），ASP.NET Core 2.0中默认是允许传递的，但如果之前手动修改过这个配置，就需要改回来。

3. 清理缓存后重新构建 #

有时候构建缓存会搞乱依赖的复制和识别，你可以试试：

• 删除解决方案根目录下所有的bin和obj文件夹；
• 打开命令行，进入解决方案目录，执行dotnet clean命令，再执行dotnet build重新构建整个解决方案，确保所有依赖都被正确处理。

补充说明 #

其实在ASP.NET Core 3.0及以后的版本中，微软优化了依赖传递的逻辑，这类问题就很少出现了，但2.0版本确实存在这个小缺陷，所以直接给项目A添加引用是最省心的解决办法。

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