从Release目录XCopy部署后NuGet依赖项加载失败问题排查

可能原因及对应解决步骤 #

1. 程序集版本不匹配 #

虽然目标目录存在System.DirectoryServices.Protocols.dll，但文件实际版本与程序依赖的6.0.0.2版本不符。

• 检查方式：分别右键查看Release目录和目标工作目录下该dll的「属性→详细信息」，对比文件版本、产品版本。
• 解决方法：确保生成后事件的复制命令全量覆盖目标目录文件，比如使用：

  xcopy /y "$(TargetDir)*.*" "你的目标工作目录路径"
  

  避免手动替换或混入其他版本的dll文件。

2. 缺失程序集绑定重定向 #

ASP.NET Core需要绑定重定向来适配依赖版本差异，但发布过程中未自动生成相关配置。

• 解决方法：在项目的.csproj文件中添加以下配置，强制生成绑定重定向：

  <PropertyGroup>
    <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
    <GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
  </PropertyGroup>
  

  重新构建发布后，确认输出目录生成了[应用名称].dll.config文件，其中包含针对System.DirectoryServices.Protocols的版本绑定节点。

3. 部署模式与服务器环境不兼容 #

若采用框架依赖部署，目标服务器的.NET Runtime版本与本地构建版本不一致，会导致依赖加载失败。

• 检查方式：在服务器运行dotnet --info，查看已安装的.NET Runtime版本是否与项目目标框架版本匹配。
• 解决方法：
  • 升级服务器上的.NET Runtime至项目对应的版本；
  • 改为独立部署模式，发布时选择「独立」选项，将所有依赖（包括.NET Runtime）打包到输出目录，消除服务器环境差异。

4. 文件权限或损坏 #

复制后的dll可能因权限不足无法读取，或复制过程中文件损坏。

• 解决方法：
  • 检查目标目录下System.DirectoryServices.Protocols.dll的权限，确保运行程序的账户拥有读取权限；
  • 删除目标目录所有文件，重新从Release目录全量复制，避免文件缺失或损坏。

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