话说月初笔者在华山之巅搞定了ASP.NET一起莫名奇妙的异常,自此之后和公主过着…嘟~~,不好意思,书都看杂了,串了台了。好,咱们闲言少叙,书归正传。
自从上次解决了由调试文件库引起的ASP.NET执行异常(详情见:华山之巅,摆平.NET――ASP.NET调试库损坏导致程序运行异常)之后,服务器一直运行的很稳定,可就在为躲过一个微软乱摆乱放的隔离墩而回首庆幸时,心神未定,又被另一个绊了一个大马趴,挣扎爬起,也顾不上脸上的灰土和身上的疼痛,赶紧掏出铅笔,在密密麻麻的隔离墩示意图上再添一笔。
昨天下班之前项目有更新,便编译打包后上传到了服务器上,一切正常。早上上班,还未坐稳,办公室便像到了中国网通总部,电话一个挨一个,急忙登录系统,发现老主顾又来了…难道是又忘了删除PDB文件了?登录服务器,却一个PDB文件也没有找到,看来并非旧病复发,而是又添新疾啊。
系统的服务使用了web service的remote模式和本地dll的local模式,双模式运行,通过配置文件可以自由切换。为了便于除错,于是将底层服务切换到local模式,登录,果然被告知“xxx组件拒绝访问”,之后是一些无用的调试信息。那既然是拒绝访问,可能是用户权限的问题,遂改之,权限放到最大,连只读属性都被注意到了。再次登录,问题依旧。
无奈,只能求助外网,到搜索引擎一打听,好家伙!被这个墩子绊倒的还不少呢。其中一点提到了微软的索引服务,一开始我并不认为跟这个八竿子打不着的东西有关系,可是也算是死马当活马医吧,姑且一试。
打开“计算机管理”“系统服务”“索引服务”,果然发现了c:/intepub被放在了编制目录里,停止、删除,再次编译程序…木哈哈哈!问题解决了!
事后绞尽脑汁,也只是得出了这么个结论:由于某种原因,索引服务数据出错,ASP.NET在编译的时候无法加载正确的库信息,从而导致了代码库的混乱。不可靠的数据简直就是乱摆乱放的隔离墩,防不胜防啊…