Azure中ASP.NET MVC5多租户应用槽位切换后权限异常排查

我之前碰到过好几个类似的案例，你的问题核心确实和应用域重启不彻底以及预编译视图的加载逻辑有关，咱们一步步拆解：

为什么会出现这个问题？ #

1. 槽交换的应用域加载异常：Azure槽交换时，虽然名义上会触发应用重启，但当你启用了视图预编译（生成PrecompiledApp.config），这个文件会改变ASP.NET加载视图的逻辑。交换过程中，可能出现旧应用域关闭后，新应用域没有正确读取PrecompiledApp.config和预编译的AppCode.dll，导致MVC路由无法映射到预编译视图，最终 fallback 到静态文件处理流程——而静态文件目录没有对应的权限配置，就出现了"You do not have permission to view this directory or page."的提示。

2. 为什么保存web.config能修复？：保存web.config（哪怕没有任何修改）会触发ASP.NET的强制应用域重启，这时候新的应用域会重新扫描所有配置文件，包括PrecompiledApp.config，正确关联预编译的视图DLL，MVC路由自然就能正常工作了。

具体解决方案 #

1. 优化槽交换的重启策略 #

在Azure Portal中进入你的Web应用 → 部署槽 → 点击“交换”按钮旁边的“配置交换设置”，确保开启**“交换时重启目标槽”**。如果已经开启，尝试在交换前先手动重启目标槽（生产槽），再执行交换操作——手动重启会比交换时的自动重启更彻底，能避免预编译资源的加载冲突。

2. 调整预编译的构建参数 #

你当前的构建参数是/p:PrecompileBeforePublish=true /p:UseMerge=true /p:SingleAssemblyName=AppCode，合并成单个DLL有时候会导致加载时的依赖问题，建议尝试：

• 去掉/p:UseMerge=true，改为分模块预编译；
• 添加/p:Updateable=false，明确标记预编译视图不可更新，让ASP.NET更稳定地加载预编译资源；
• 测试/p:PrecompileBeforePublish=true /p:SingleAssemblyName=AppCode（去掉UseMerge）的效果，看是否还会出现交换后的异常。

3. 自动触发修复性重启脚本 #

如果上面的方案不能彻底解决，可以在槽交换完成后，自动触发一次应用域重启（相当于手动保存web.config的效果）。用Azure PowerShell脚本实现：

# 替换为你的Web应用和资源组名称
$webAppName = "your-webapp-name"
$resourceGroupName = "your-resource-group"

# 调用Kudu API触发应用重启
$kuduApiUrl = "https://$webAppName.scm.azurewebsites.net/api/restart"
$publishProfile = Get-AzWebAppPublishingProfile -Name $webAppName -ResourceGroupName $resourceGroupName -Format WebDeploy
$username = $publishProfile.PublishProfile[0].UserName
$password = $publishProfile.PublishProfile[0].UserPWD
$base64Auth = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes("$username:$password"))

Invoke-RestMethod -Uri $kuduApiUrl -Headers @{Authorization="Basic $base64Auth"} -Method POST

把这个脚本加到Azure DevOps或者GitHub Actions的部署流程中，作为槽交换后的后续步骤，自动修复重启问题。

4. 完善web.config的模块配置 #

你已经设置了runAllManagedModulesForAllRequests="true"，但可以再补全ExtensionlessUrlHandler的配置，避免模块加载冲突：

<system.webServer>
  <modules runAllManagedModulesForAllRequests="true">
    <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
    <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
  </modules>
  <handlers>
    <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
    <remove name="OPTIONSVerbHandler" />
    <remove name="TRACEVerbHandler" />
    <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
  </handlers>
</system.webServer>

先移除默认的Handler再重新添加，能确保无扩展名的MVC路由被正确处理，不会被静态文件模块拦截。

总结 #

这个问题本质是预编译视图在Azure槽交换时的加载异常，核心是应用域没有正确初始化预编译资源。保存web.config是强制触发了正确的重启，所以解决思路要么让槽交换时的重启更彻底，要么调整预编译配置让加载更稳定，要么自动触发修复性重启。

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