再次证明了测试是多么的重要,之前一直不解的服务器不能写xml的问题终于找到原因。一直都猜是IIS的权限不允许写入文件,结果发现原来根本不是这么一回事,仅仅是服务器端的逻辑判断有问题,进一步追查就是数据库查询接口的bug。翻查一下UnitTest,果然没有测试过查询接口,也导致了问题的发生。
另外目前发现了几个wcf的问题。首先原来的404错误现在知道还跟服务还没启动成功有关。另外返回null以及""(空字符串)会造成客户端无限等待,不知道为何采用http协议却会有这样的问题。按道理每条消息都会有http头,客户端应该可以判断得到,但事实是客户端判断不了,不知道是不是bug……
中午更新:
终于搞清楚一切的来龙去脉了。原来之前的猜测都错了,确实是服务器写xml失败导致了所有的错误!
首先第一次register的时候服务器执行记录插入,但是在写xml的时候失败,结果返回了404错误,被我误认为是服务器没启动。然后再次register,虽然xml没有写入,但是ado.net保存了记录,结果记录重复,自然会返回false,结果又被我误认为是if语句错误……
至于不能传""纯属客户端的问题,因为我在底层屏蔽了""的结果。看来有些不应该放在底层的东西就不应该放,设计确实是难呀!
另外目前发现了几个wcf的问题。首先原来的404错误现在知道还跟服务还没启动成功有关。另外返回null以及""(空字符串)会造成客户端无限等待,不知道为何采用http协议却会有这样的问题。按道理每条消息都会有http头,客户端应该可以判断得到,但事实是客户端判断不了,不知道是不是bug……
中午更新:
终于搞清楚一切的来龙去脉了。原来之前的猜测都错了,确实是服务器写xml失败导致了所有的错误!
首先第一次register的时候服务器执行记录插入,但是在写xml的时候失败,结果返回了404错误,被我误认为是服务器没启动。然后再次register,虽然xml没有写入,但是ado.net保存了记录,结果记录重复,自然会返回false,结果又被我误认为是if语句错误……
至于不能传""纯属客户端的问题,因为我在底层屏蔽了""的结果。看来有些不应该放在底层的东西就不应该放,设计确实是难呀!