.NET 6应用部署失败：主DLL被锁定的解决方案咨询

一、修复app_offline.htm的无效/重启失败问题 #

你遇到的移除app_offline.htm后站点无法重启，大概率是文件配置或操作流程的问题，调整后就能正常工作：

• 保证文件大小≥1KB：IIS对过小的app_offline.htm会忽略，没法触发站点关闭逻辑。可以在维护提示文本外多添加些空白字符填充，确保文件达标。
• 严格遵循操作顺序：先上传app_offline.htm，等待10-15秒确认站点进入维护状态，再替换所有DLL和依赖文件，最后删除app_offline.htm。不要跳过等待步骤，给IIS足够时间释放文件锁。
• 移除后等待自动重启：IIS会在检测到app_offline.htm被删除后的30秒内自动重启应用池，不要手动强制终止w3wp进程，否则容易导致站点启动异常。如果超过时间没反应，检查应用池的「快速失败保护」是否触发，可临时禁用后重试。

二、从根源避免DLL锁定的长效方案 #

1. 启用应用池影子复制 #

在IIS的应用池高级设置里开启「启用影子复制」，IIS会将站点的DLL和依赖文件复制到系统临时目录运行，原部署目录的文件就不会被锁定，部署时直接替换即可。注意：.NET 6独立部署（Self-Contained）需确保影子复制覆盖所有发布生成的文件。

2. 使用部署槽（Deployment Slots） #

如果你的环境支持（比如Azure App Service、IIS的ARR路由槽位），这是生产环境最优解：将新版本部署到 staging 槽，测试验证通过后一键交换到生产槽，全程零停机，完全绕开DLL锁定问题。

3. 采用WebDeploy自动化部署 #

用WebDeploy的「就地更新」模式部署，它会自动处理文件锁定逻辑：部署前先停止相关进程、释放文件锁，替换完成后自动重启站点，无需手动操作app_offline.htm。

4. 排查代码中的资源泄漏 #

如果以上方案都没彻底解决，排查应用程序本身是否存在未释放的文件句柄：用Process Explorer工具找到锁定DLL的进程，检查是否是代码中未关闭的FileStream、第三方组件的资源泄漏导致的。修复代码中的资源释放问题，从根源消除锁定。

三、应急处理：已锁定时的快速解决办法 #

• 优雅重启应用池：用命令行appcmd recycle apppool /apppool.name:"你的应用池名称"或IIS管理器重启应用池，比手动杀w3wp进程更安全，能避免站点启动失败。
• 用robocopy同步文件：部署脚本里用robocopy /MIR /R:3 /W:5命令替换普通复制，它会自动重试被锁定的文件，直到替换成功，适合自动化部署场景。

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