Home/ Questions/Q 3300550
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-17T20:40:21+00:00

We have a WCF service that is deployed to two servers. The bits are

  • 0

We have a WCF service that is deployed to two servers. The bits are exactly the same.

In the auto-generated WSDL at https://mywebsite.com/SomeService/Soap.svc?wsdl, the <wsdl:types> node lists out a bunch of XSD’s, in this format:

<xsd:import schemaLocation="https://mywebsite.com/SomeService/Soap.svc?xsd=xsd0" namespace="http://services.mywebsite.com/account" /> 
...
<xsd:import schemaLocation="https://mywebsite.com/SomeService/Soap.svc?xsd=xsd6" namespace="http://schemas.datacontract.org/2004/07/SomeOtherNamespace" />

This is all fine and good, but the problem is the order of the XSD’s is different on each load-balanced server, even though they have the same bits. This means the XSD at https://mywebsite.com/SomeService/Soap.svc?xsd=xsd0 is very different on each server, and this is obviously causing issues for those consuming the service.

I’m aware there are code solutions to flatten the WSDL and include all the XSD’s in it. However, is there any simple solution to just force the WSDL’s to match? After all, it is the same bits on each machine.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Generated XSD are differents but messages are the same. What differs are namespace prefixes and orders in XSDs. If you want only one version of the WSDL, I suggest you to disable loadbalancing on ?wsdl and ?xsd URLs.

    Nonetheless, the bottom-up (code to wsdl) approach for webservice is definitely not the best one for production environment. The WSDL is the contract between you and your clients, it should therefore not be dynamically created and must be fixed for the current release of your web service application.

    • 0