Wsdl issue with servicestack types

ServiceStack SOAP
1

Following wiki guidelines for soap, we customized WsdlServiceNamespace with our ns so we did at ServiceModel leveraging on the assembly: ContractNamespace… option to set the same ns for all our operations.
All our Operations/ResponseDTOs implement IHasResponseStatus so they include ResponseStatus SS built-in type.
Doing so the wsdl can be successfully parsed by clients such as SOAPUI and/or VS AddServiceReference/svcutil.
The problem is the soap response that contains ReponseStatus type belonging to “http://schemas.servicestack.net/types” (due to ServiceStack.Interfaces dll has the AssemblyInfo directive forcing that ns for all types within the ServiceStack C# ns.) while the wsdl says the ReponseStatus type belongs to our custom ns (due to WsdlServiceNamespace value) - while the /metadata?xsd=n uses the correct/built-in SS ns.
The reason why the wsdl uses our custom ns instead of the one set within the ServiceStack.Interfaces AssemblyInfo is the following code within ServiceStackHost

    public virtual string GenerateWsdl(WsdlTemplateBase wsdlTemplate)
    {
        var wsdl = wsdlTemplate.ToString();

        wsdl = wsdl.Replace("http://schemas.datacontract.org/2004/07/ServiceStack", Config.WsdlServiceNamespace);

        if (Config.WsdlServiceNamespace != HostConfig.DefaultWsdlNamespace)
        {
            wsdl = wsdl.Replace(HostConfig.DefaultWsdlNamespace, Config.WsdlServiceNamespace);
        }

        return wsdl;
    }

Due to the ns mismatching, the soap response cannot be deserialized because the client(VS AddServiceReference) built the DataContract according to to the wsdl using our custom ns while it receives the SS built-in ns for the ResponseStatus type.

2

You can override this built-in behavior by overriding GenerateWsdl in your AppHost so it doesn’t replace the WSDL, e.g:

public override string GenerateWsdl(WsdlTemplateBase wsdlTemplate)
{
    var wsdl = wsdlTemplate.ToString();
    return wsdl;
}
3

Thanks, that’s what we already did as temporary workaround.
But still the question is why? why generating a custom wsdl that does not match with the runtime?
I mean, the auto-generated documentation does not match with the wsdl so the client proxy generated against the customized wsdl does not work properly.
IMHO the wsdl customization requires a review…, do not allow the wsdl ns customization at all(stick w/ SS ns) is not an option, a customized wsdl not matching w/ the runtime is even worst.

4

This was done to work around issues with other WSDL generated proxies. WSDL’s and SOAP are extremely fragile with different generators having different incompatibility issues. Hence why we only support a single namespace, preferably the SS namespace since it yields the least issues.

The more you try to customize WSDL’s and SOAP the more likely you are to run into issues. Maybe your best approach is to use a custom SS build after all - with your preferred namespace and naming convention applied to all DTO’s. Personally I’d be looking at using Add ServiceStack Reference instead: Cleaner, faster, simpler, richer and more robust and flexible with fewer moving parts and complete control end-to-end.

5

Thanks Demis, one again I agree with you 100% about the soap/wsdl point of view and if I have to choose, I go for “Add ServiceStack Reference”
But the point here is that a built-in SS feature (support for wsdl with custom ns → “Config.WsdlServiceNamespace”) is not fully working: are you considering to review the wsdl generation?

that workaround may resolve the wsdl itself, but it compromised its purpose: create a client proxy able to send a valid request and handle/deserialize a response.

Said so. since we are not using via soap non of the SS operations, we actually totally removed from the WSDL, but maybe only one SS type (ResponseStatus), we go for the wsdl customization you propsed or we try to avoid to use also that type as well as per my other current open post.