SoapSuds工具的一些不足之处
Some shortcomings of SoapSuds tool
SoapSuds是.Net Framework提供的一个很有用的工具，用来在生成Remote Objects或Web Services的元数据（metadata），供Client端引用。但是，SoapSuds也存在一些不足之处，在使用过程应加以注意，然后通过一些措施进行解决。
1，不能提取非缺省构造函数（nondefault constructor）的元数据，如果Remote Objects的构造函数有传入参数，SoapSuds不能够提取这部分的元数据。
解决措施：使用SoapSuds提取Remote Objects元数据的源代码，手工修改/添加这部分的元数据，然后在Client端引用。（怎么改源代码？我还没有试过。）
SoapSups –url:<URL> -nowp –gc
SoapSups –ia:<Assembly> - nowp –gc
2，如果Remote Objects引用[Serializable] Class，那么通过SoapSuds则不能正确提取Remote Objects的元数据。
问题如下：通过SoapSuds 对Remote Objects提出的元数据不仅包括Remote Object本身，而且还有[Serializable] Class的元数据信息。（This is because SoapSuds generates metadata-only assemblies for all classes and assemblies that are referenced by your server.）如下图所示：
（有人可能会想，这样不是很好吗？直接给Client端这个DLL文件就可以了，[Serializable] Class的Shared Assembly都不需要提供给Client端了。）
如果感兴趣，可以分析SoapSuds生成的源代码或者Assembly（ILDASM工具），看上述观点是否正确。（我测试过，确实是这样的！）
如果同时在Client端引用[Serializable] Class的Shared Assembly和SoapSuds生成的Assembly，会出现Namespace冲突等异常。
如果在Client端只引用SoapSuds生成的Assembly，那问题是[Serializable] Class的元数据有问题呀。
解决措施：
（1）使用SoapSuds提取Remote Objects元数据的源代码，现在你打开生成的源代码，发现没有[Serializable] Class的元数据。（呵呵，这正是需要的）将这个源代码生成Assembly或者直接供Client端调用均可。
（2）同时在Client端引用[Serializable] Class的Shared Assembly。
这样，Client端需要引用两个文件。
Reference:
1. Ingo Rammer, Advanced .Net Remoting
2. MSDN
