当从xsd / wsdl（通常是从类生成）中轻松生成代理类时，一切正常。
但是当wsdl / xsd不是来自MS世界时，作为包含数十甚至数百个文件的zip包，则代理生成通常会失败。在这种情况下，你会尝试理解什么是错的，可能会尝试纠正wsdl，找到你需要的类型，只留下它们，找到错过的包含等，或者放弃并没有代理服务？
我不觉得用xpath查询XmlDocument，并从字符串/文件模板创建骨干文件感到不舒服，但每次遇到“坏”wsdl / xsd我花了一些时间来纠正它......后来后悔这个即使成功，因为设置无限代理的字段与设置无限文档的元素和属性完全相同。
除了一些原始的编译器检查，代理类给开发人员带来了什么价值？可能是我忘记了......
答案 0 :(得分：1)
一般来说我从xsd工作过非常积极。在少数情况下它失败了，我发现一种务实的方法（如果你有可用的样本xml）是使用xsd.exe工具来生成的东西，即使不是理想的类型，至少匹配xml。当然，您可能需要与您喜欢的几个string成员一起生活，或者手动调整它们。
调整xsd（以解决您副本中没有的任何更改，或者破解工具不支持的xsd选项）可能是一个明智的选择，但很难判断多长时间你可能需要花在那条路上。
重新获得价值：嗯，当它工作时，获得一个可以作为DTO层的对象模型是一种非常公平的方式。通常它 工作。但并非总是如此。它听起来就像你的场景有大/复杂/多个xsd一样，所以手工完成所有翻译代码（通过xml查询，或从头开始编写你自己的DTO模型）可以是批次的工作。
Xsd可以（也应该）用作验证您传递的xml 继续以遵守已发布定义的工具。在处理xml数据导入时，我多次尝试通过xsd验证器进行扫描（幸运的是XmlReader将在.NET中执行此操作。）