aspx网站打不开

周一早上九点，网站客户电话打过来，网站说后台进不去了。网站我打开浏览器，网站输入那个用了三年的网站域名，转圈，网站然后白屏。网站F12一看，网站500 Internal Server Error。网站服务器没挂，网站ping得通，网站远程桌面也能连。网站问题出在IIS或者.NET运行时这一层。网站

先看Windows事件查看器。网站应用程序日志里一堆红色错误，网站来源是ASP.NET 4.0.30319，事件代码1309。描述写着“加载程序集时出错”，具体是某个.dll文件找不到或者版本对不上。这种情况我碰过几次，大多是bin目录被覆盖了一半，或者服务器上装了新的.NET Framework补丁，把旧的程序集引用搞乱了。

SSH进去翻目录。网站根目录下bin文件夹里，那个主项目的dll还在，但依赖的几个第三方库少了两个。问了一下，上周五运维同事手动传过文件，可能是FTP断线导致上传不完整。把备份的bin目录整个覆盖回去，重启应用程序池。刷新页面，还是500。

那就不是单纯丢文件的问题。打开web.config，看<system.web>节点下的<compilation>配置。debug设成了true，targetFramework是4.7.2。服务器上实际安装的.NET版本是4.8，按理说向下兼容没问题。但IIS的应用程序池设置里，.NET CLR版本选的是“无托管代码”。这就矛盾了——一个ASP.NET网站跑在无托管代码的池子里，等于让鱼在树上爬。

改成v4.0，回收池子。再试，错误变了。这次是“未能加载文件或程序集‘System.Web.Mvc, Version=5.2.7.0’”。明明bin目录里有这个文件，版本也对。问题出在IIS的临时编译目录。ASP.NET会把网站动态编译到C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\下面。那个目录里缓存了旧版本的引用，跟bin里的新dll打架。清空这个临时目录，再重启IIS。页面终于出来了。

但事情没完。首页能打开，点进子页面又报错，提示“无法找到资源”。查看路由配置，发现Global.asax里注册的路由规则加载失败。原因是刚才清空临时目录后，第一次请求触发了全量编译，某个.cshtml视图文件里引用了不存在的命名空间。这个视图文件是半年前改过的，但当时没重新编译就丢上去了，一直靠旧缓存撑着。现在缓存没了，问题暴露出来。

把那个视图文件的引用删掉，重新发布。这次学乖了，发布前先本地跑一遍，确认bin目录和views目录完整。再用Web Deploy而不是FTP上传，避免文件不完整。上线后观察半小时，没再报错。

回头看，aspx网站打不开，表面是500错误，根因往往藏在三层：IIS配置、.NET运行时版本、程序集缓存。运维习惯用FTP手动传文件，开发习惯本地调试完直接丢dll，两边一凑，迟早出事。我后来给这个项目加了个简单的健康检查接口，每次发布后自动请求一次，返回200才算成功。省得下次又靠客户打电话来发现问题。

还有个小细节。那个Temporary ASP.NET Files目录，默认权限只给了SYSTEM和IIS_IUSRS。如果应用程序池身份改成了自定义账户，比如NetworkService或者自己建的域账户，没有这个目录的写权限，照样打不开。我见过有人排查一整天，最后发现是权限问题。Windows事件日志里会写“访问被拒绝”，但错误信息很隐晦，得翻到最底下看内部异常。

所以现在我的排查顺序固定了：先看事件查看器里ASP.NET的具体错误代码，再查应用程序池的托管管道模式和.NET版本，然后清临时编译目录，最后检查bin和web.config。四步走完，九成问题能定位。剩下的那一成，多半是服务器磁盘满了或者杀毒软件锁了dll文件。这种就得靠经验堆了。