通过几天的分析，终于找到不能在IIS中利用WAS寄宿TCP协议的WCF服务的原因了。事实证明所犯的错误是如此低级和愚蠢——真实的命名空间和ServiceContractAttribute中的命名空间不相同。
参照网上的示例，我做了一个在IIS中利用WAS寄宿TCP协议的WCF服务的示例，但不能正常工作。我将其换成HTTP协议之后，没问题。于是我认为肯定是TCP配置的那些环节出了问题（事实上，这个判断是我浪费时间的起点）。很多时间花在百度和谷歌上搜索信息了，有很多错误信息相同的错，但是所有找到的解决方案都不可行。
在我就要放弃的时候，我想到徐长龙老师的Demo，我就把他的Demo下载下来去运行。我期望的结果是，这个他的demo也不能正常运行。结果大出我的意料，他的demo竟然成功了，并且让我看到了svcutil.exe net.tcp://my_machine/TcpActivation/Calculator.svc/mex。狂喜！之后我比较了我们的配置文件，发现他们除了命名空间和服务名几乎是一模一样。我先把服务名改成相同的，还是不行。一气之下，我就准备连命名空间也改了。这时候，我发现我的demo中的真实的命名空间和ServiceContractAttribute中的命名空间不想同。而徐老师的demo中，他们是相同的。一开始，我并不认为这种不同会有什么问题。因为在ASP.NET和XML中，命名空间只是一种标识，只要具有惟一性就行。但是，我还是把他们改成相同的了，因为，确实没有别的方法可以尝试了。结果，一经改成相同的，程序就正常运行了。那一刻，我不知该哭还是该笑。。。
我估计很多人不会犯我的错，不是有能力避开，而是习惯使然，不会犯错。这让我有以下感慨：
1、Design time所犯的错不易调试，那么为了可读性等等因素而添加的东西，是否真的对程序没有影响？
2、当错误出现而我们又不能轻易找到错误原因的时候，我们会将手头的东西一再简化，甚至简化到只留下模板的内容。问题是那些你认为99+%没问题的地方，你会改回模板的样子吗？
后记：
事实证明，真正的原因是代码中的命名空间与配置文件中的不同。我本有意将这篇博文删掉，但又想想，还是留下来以告诫自己真正的原因并不那么好找。别人遇到同样的问题，也可以节省时间。