ServiceStack Hello World示例不生成Soap代理

Question

我刚刚从nuget（从3.9.11到3.9.56版）更新了对新ServiceStack的引用，但我的肥皂客户端无法正常工作。 因此，我决定再次尝试[github]（ https://github.com/ServiceStack/ServiceStack.Examples/tree/master/src/ServiceStack.Hello ）上提供的Hello World解决方案，该解决方案正在使用旧版本。 （32年9月3日）。

我在Hello和HelloResponse类上添加了[DataContract]属性，然后尝试通过向本地soap12端点添加服务引用来构建C＃控制台客户端（使用VS2010上的“添加服务引用”，也尝试了2012和2013）。 不幸的是，虽然我获得了OneWayClient和SyncReplyClient ，却没有生成任何DTO。 这是为什么？ 我尝试使用ServiceStack的较早版本（使用IService<T>和Execute方法）构建代码，并且一切正常！是否有我不知道的重大更改？

PS我也尝试针对nuget库重新编译整个ServiceStack.Examples项目，但它也失败了。 我什至无法生成代理。 请不要试图说服我为我的DTO使用共享程序集，因为这违背了使用与语言无关的Web服务的目的！

Answer 1

请不要试图说服我为我的DTO使用共享程序集，因为这违背了使用与语言无关的Web服务的目的！

听起来不像是把事情做好。 不知道您认为服务的目的是什么，但不是要实现复杂的WS- *规范（已死），甚至不能安抚某些专有的代码生成代理工具，尤其是那些生成RPC方法签名耦合代码的工具。 -gen类型生成代理客户端，仅限于使用效率低下且膨胀的SOAP格式，该格式可以说是当今Web服务实现中使用的最脆弱的技术组合 。

服务的目的实际上是...只是提供服务-封装一些功能并以尽可能可访问，可容忍和可互操作的方式远程提供，理想地以最少的工作量，摩擦和复杂性有效地进行。

不确定为什么您认为SOAP生成的代理是获得与语言无关的Web服务的门票吗？ 鉴于代码生成代理实现通常是弱的，不完整的，并且在企业内部不流行的平台上已被弃用。

WSDL的全部目的是提供一些机器可读的规范，代码代代理可以使用该规范来生成类型化的服务客户端-这是WSDL（不是服务）的目的-一种为达到目的的工具（用于提供与服务的连接）。 但是在所有复杂性和封闭源黑盒工具的作用下，它仍然无法重新创建在服务器上开发和维护的干净的DTO类型。 但是，您只需将.dll（或源代码）复制到.NET客户端项目中，就可以避免所有的人工操作和复杂性，并与Server DTO保持对称奇偶校验，从而可以使用ServiceStack的任何通用.NET Service Clients提供能够以任何受支持的格式（甚至内置WCF / SOAP客户端）重用相同的DTO，因为通用类型的客户端是可替换的。

不推荐使用WS-* / SOAP，因为它不必要地复杂，它是在错误的前提下构建的，即要提供“可互操作的服务”，您需要抽象，明确和选择复杂性。 相反的事实是，使用简单的格式和简单的URI，您将获得更好的互操作性，更少的工作量和更少的摩擦，这就是为什么今天的新Web API不支持SOAP的原因。

Answer 2

我终于解决了这个问题，因此我将在此处发布答案。 尽管GitHub存储库上的所有示例都需要更新才能与最新版本一起使用，但ServiceStack并没有看上去那么糟糕。 因此，要点是：如果您希望您的类正确生成代理类，则不仅需要在类级别使用[DataContract]属性，而且还要在属性级别使用[DataMember]装饰它们，即

[DataContract]
class User
{
    [DataMember]
    public String Name { get; set; }
}

当然，你也需要或者指定的命名空间[DataContract]属性（单声道兼容性），或者你将有描述在AssemblyInfo.cs中添加几行这里 。

但是要警告！ 您所有的DTO（包括请求类型和响应类型）都应该在同一名称空间上！ 同样，如果您仅将一级类定义为请求类型（例如我使用的用户示例），那么您将不会获得代理类！ 相反，所有公共成员将成为方法参数。 如果您通过构成在User类中拥有另一个公共成员，即

[DataContract]
class User
{
    [DataMember]
    public String Name { get; set; }
    [DataMember]
    public MyClass MyMember { get; set; }
}

那么您将获得MyClass的代理，但不会获得User的代理。 至于响应类型，最好阅读ServiceStack Wiki上有关SOAP的限制 。

最后说明：我通常只对灵活性，简单性，寻找替代方案和使事情起作用有很强的见解。 我发现毫无意义的讨论试图通过一种工具使生活变得比硬编码更为轻松，这些讨论试图以另一种语言来支持一种语言，以另一种语言来支持体系结构，以一种流行的方式/利基技术来代替标准方法。 因此，我认为对上述评论的讨论是如此，我希望不再继续。

我很高兴像ServiceStack这样的出色工具能够继续为大多数用户提供其使用目的： 多种选择。