使用Advanced Installer部署从.NET Core 2.2升级至.NET 5.0的应用时出现HTTP 500.31错误求助

这种情况我之前帮团队排查过类似的，核心矛盾点在于手动复制发布产物正常，但安装程序部署就丢依赖，大概率是Advanced Installer的打包逻辑没正确处理.NET 5的原生依赖包，或者部署时的文件处理有差异。下面是一步步的排查和解决思路：

1. 先确认安装包是否包含了Microsoft.Data.SqlClient.SNI.runtime的原生文件 #

Microsoft.Data.SqlClient.SNI.runtime是个原生依赖包，它的内容不在主程序集里，而是放在发布产物的runtimes目录下（比如runtimes/win-x64/native/Microsoft.Data.SqlClient.SNI.dll）。手动复制时会完整带上这个目录，但Advanced Installer默认可能不会自动识别这类原生依赖：

• 打开你的Advanced Installer项目，切换到Files and Folders视图
• 检查目标安装目录下是否存在runtimes文件夹，以及里面对应平台的原生dll
• 如果没有，找到你发布后的publish目录，把整个runtimes文件夹添加到安装包的文件组中，确保部署时会完整复制到目标路径

2. 验证发布命令是否生成了完整的依赖 #

你的发布命令是：

dotnet build %projFile% -p:DeployOnBuild=true -p:PublishProfile=%pubProf% -p:Configuration=Release -v n

可以做以下调整和检查：

• 先单独执行一次发布命令，查看输出的publish目录里是否有runtimes文件夹，如果没有，说明发布过程就没包含这个依赖：
  • 确认项目里的Microsoft.Data.SqlClient包版本和Microsoft.Data.SqlClient.SNI.runtime版本匹配（两者版本要一致）
  • 在发布命令里添加-p:IncludeNativeLibrariesForSelfExtract=true（如果是自包含部署），或者检查PublishProfile文件里是否有<IncludeNativeLibraries>true</IncludeNativeLibraries>配置
• 如果发布后的publish目录是完整的，那问题就出在Advanced Installer没有把这些文件纳入安装包

3. 检查部署后的文件权限与完整性 #

即使安装包包含了文件，有时候安装程序在部署时可能会修改文件权限，或者没有正确解压原生dll：

• 用Advanced Installer部署完成后，手动到目标服务器的网站目录下，检查runtimes文件夹是否存在，里面的dll是否和本地发布的一致
• 对比手动复制后的文件权限，确保应用池身份（比如IIS AppPool\你的应用池名称）对runtimes目录及其子文件有完全控制权限（虽然你说已经给了整个目录权限，但还是确认下原生dll的权限是否继承了父目录）

4. 调整Advanced Installer的打包逻辑，模拟手动复制 #

有些安装工具会对.NET应用的文件做“优化”过滤，导致漏掉原生依赖：

• 尝试把整个发布后的publish目录作为一个文件夹整体添加到Advanced Installer的文件组，而不是单独添加项目输出文件
• 检查Advanced Installer里的**.NET Settings**，确保它正确识别了.NET 5.0运行时，并且启用了“Include all dependencies”之类的选项（不同版本的Advanced Installer选项名称可能有差异）

5. 最后确认IIS应用池的CLR设置 #

虽然手动部署正常，但还是快速核对下：IIS应用池的**.NET CLR版本**必须设置为无托管代码，因为.NET 5是跨平台的非托管运行时，这个设置如果安装程序配置错误，也可能导致依赖加载失败（不过手动复制正常的话这个概率较低，但排查时可以排除）

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