Search code examples
c#.netservicestackasmxservicestack.redis

How to specify "namespace" and "conformsto" attribute to APIs for services developed using ServiceStack?


We are currently in process of converting our legacy web services (asmx) into REST APIs layer developed using ServiceStack platform.

There exists a few Web services having the namespace and Binding ConformsTo attributes specified in asmx. Following is one such example:

[WebService(Namespace = "http://ourcustomsite.com/externalServices")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]

How can we set them in their ServiceStack counterpart?


Solution

  • If you're referring to ServiceStack's SOAP Support it only supports changing the namespace using .NET DataContract attributes which should be specified for each namespace that your DTOs (aka ServiceModels) are in, e.g:

    [assembly: ContractNamespace("http://ourcustomsite.com/externalServices",
               ClrNamespace = "MyApp.ServiceModel.Operations")]
    [assembly: ContractNamespace("http://ourcustomsite.com/externalServices",
               ClrNamespace = "MyApp.ServiceModel.Types")]
    

    You'll also want to specify your custom namespace on:

    SetConfig(new HostConfig {
        WsdlServiceNamespace = "http://ourcustomsite.com/externalServices",
    });
    

    ServiceStack's SOAP bindings are not customizable and is not designed to be used to conform to a profile of an existing SOAP Service. SOAP clients need to use the /soap11 and /soap12 WSDLs to generate the WCF Service Reference clients or even better the generic Soap12ServiceClient which can use your Services existing typed DTOs instead of a WSDL generated proxy.

    Avoid SOAP for new Projects

    Usage of SOAP should be considered legacy and limited to situations where their usage is mandated. Add ServiceStack Reference together with ServiceStack's generic C#/.NET Service Clients offers a much faster, simpler, versatile and resilient alternative to SOAP that can be utilized in a number of different C#/.NET Clients in a number of different languages and should be the preferred solution when its usage is an option.