索引服务混战ASP.NET――微软的又一个隔离墩

2018-06-17 19:48:53来源:未知 阅读 ()

新老客户大回馈,云服务器低至5折

    话说月初笔者在华山之巅搞定了ASP.NET一起莫名奇妙的异常,自此之后和公主过着…嘟~~,不好意思,书都看杂了,串了台了。好,咱们闲言少叙,书归正传。

    自从上次解决了由调试文件库引起的ASP.NET执行异常之后,服务器一直运行的很稳定,可就在为躲过一个微软乱摆乱放的隔离墩而回首庆幸时,心神未定,又被另一个绊了一个大马趴,挣扎爬起,也顾不上脸上的灰土和身上的疼痛,赶紧掏出铅笔,在密密麻麻的隔离墩示意图上再添一笔。

    昨天下班之前项目有更新,便编译打包后上传到了服务器上,一切正常。早上上班,还未坐稳,办公室便像到了中国网通总部,电话一个挨一个,急忙登录系统,发现老主顾又来了…难道是又忘了删除PDB文件了?登录服务器,却一个PDB文件也没有找到,看来并非旧病复发,而是又添新疾啊。

    系统的服务使用了web service的remote模式和本地dll的local模式,双模式运行,通过配置文件可以自由切换。为了便于除错,于是将底层服务切换到local模式,登录,果然被告知“xxx组件拒绝访问”,之后是一些无用的调试信息。那既然是拒绝访问,可能是用户权限的问题,遂改之,权限放到最大,连只读属性都被注意到了。再次登录,问题依旧。

    无奈,只能求助外网,到搜索引擎一打听,好家伙!被这个墩子绊倒的还不少呢。其中一点提到了微软的索引服务,一开始我并不认为跟这个八竿子打不着的东西有关系,可是也算是死马当活马医吧,姑且一试。

    打开“计算机管理”?“系统服务”?“索引服务”,果然发现了c:\intepub被放在了编制目录里,停止、删除,再次编译程序…木哈哈哈!问题解决了!

    事后绞尽脑汁,也只是得出了这么个结论:由于某种原因,索引服务数据出错,ASP.NET在编译的时候无法加载正确的库信息,从而导致了代码库的混乱。不可靠的数据简直就是乱摆乱放的隔离墩,防不胜防啊…

标签:

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有

上一篇:ASP.NET页面刷新的实现方法总结

下一篇:c#中何时使用Empty()和DefalutIfEmpty()