This is a copy from originally published in , now link dead

How to control WSDL namespaces in WCF is a common question, so I will tackle this first. I will assume WSDL basics to be known.

WSDLs exported by WCF

WCF services by default export a tree of WSDLs, i.e. several WSDLs, imported one from another using wsdl:import construct.

This is because different WSDL elements exported by WCF service have different lifecycles: wsdl:service, wsdl:binding, wsdl:portType and schemas.  For example schemas are prescribed by vertical industry standard; contract is written once for all providers; binding is prescribed by a vertical industry standard; service is implemented by individual provider.

Each of these WSDL elements has a namespace uri associated with it. In WSDL such namespace uri is assigned by the @targetNamespace attribute on <wsdl:definitions> root that contains one of these elements. Hence there are four types of namespaces in WSDLs generated by WCF.

There is always one WSDL generated for one target namespace URI. I.e. if the namespaces uris match for wsdl:portType and wsdl:binding , these elements are bundled into the same WSDL. XML Schemas are always exported as separate documents.

Compatibility note:

wsdl:import – the construct that allows to build the WSDL tree and put wsdl:service, wsdl:binding and wsdl:portType into different namespaces – was not very well supported by early toolkits. For example if your service is required to be consumed by early versions of InfoPath or Visual Studio ATL  sproxy.exe tool, you will need to set the target namespaces for wsdl:service, wsdl:binding and wsdl:portType to the same URI.

Control WSDL Namespaces

Here is how you control target namespaces for wsdl:service, wsdl:binding , wsdl:portType and schemas. WSDL has also wsdl:message – those are bundled together with the wsdl:portType

Service namespace

This is the target namespace of the root WSDL where <wsdl:service…/> element resides containing endpoints (<wsdl:port>)


Set via ServiceBehavior attribute on the service class (not the contract!)

[ServiceBehavior(Name=”MyService”, Namespace=”;,


public class MyService : IMyServiceContract

default for ConfigurationName (used in config) and Name (exported name into WSDL) is the name of the class. Default for the namespace is the “”


<wsdl:definitions name=”MyService”  targetNamespace=”; …>

<wsdl:service name=”MyService”>

Note, we had an unfortunate bug in RC0 that caused stack overflow when you used this setting. This is fixed in later bits.

Binding namespace

This is the target namespace for the WSDL that contains wsdl:binding elements. wsdl:binding is where WCF exports bindings together with certain serialization aspects.



<service name=”MyServiceConfiguration”…>

<endpoint name=”MyServiceEndpoint”


contract=”Namespaces.MyServiceContract” …>


Binding b = new CustomBinding();

b.Namespace = “;;

se = sh.AddServiceEndpoint(typeof(MyServiceContract), b, “;);


<wsdl:definitions targetNamespace=”; …>

<wsdl:binding name=”MyServiceEndpoint”>

Contract namespace

This is the target namespace for the WSDL that contains wsdl:portType . ServiceContract is exported there.


[ServiceContract(Name = “MyServiceContract”, Namespace = “;)]

public interface MyServiceContract {}


<wsdl:definitions targetNamespace=””&gt;

<wsdl:portType name=”MyServiceContract”>

Schema namespace

DataContract types , XmlSeriazer types and wrapper elements defined by MessageContract are being exported into schemas.  Schemas namespace are set on individual DataContract , XmlSerializer or MessageContract attributes.


[DataContract(Name=”Order”, Namespace=”;)]

public class Order



public string Id;


[MessageContract(IsWrapped = true, WrapperNamespace=”;)]

public class MyServiceUpdateRequest


[MessageBodyMember(Namespace = “;)]

public Order Order;



wsdl:types is always put into the same WSDL as wsdl:portType. It always contains a single xsd:schema referencing all the schemas used by that portType.

<wsdl:definitions targetNamespace=””&gt;


<xsd:schema targetNamespace=””&gt;

<xsd:import schemaLocation=”; namespace=””/&gt;

<xsd:import schemaLocation=”;


<xsd:import schemaLocation=”; namespace=””/&gt;



<wsdl:message name=”MyServiceUpdateRequest”>

<wsdl:part name=”parameters” element=”q1:MyServiceUpdateRequest” xmlns:q1=””/&gt;



<xs:schema elementFormDefault=”qualified” targetNamespace=”; xmlns:xs=”; xmlns:tns=””&gt;

<xs:import schemaLocation=”http://localhost:8080/?xsd=xsd2&#8243; namespace=””/&gt;

<xs:element name=”MyServiceUpdateRequest”>



<xs:element minOccurs=”0″ name=”Order” nillable=”true” type=”q1:Order” xmlns:q1=””/&gt;





<xs:schema elementFormDefault=”qualified” targetNamespace=”; xmlns:xs=”; xmlns:tns=””&gt;

<xs:complexType name=”Order”>



<xs:element name=”Order” nillable=”true” type=”tns:Order”/>


Note there is the third schema whenever you use DataContract / XmlFormatter as a formatter for your service contract. This defines several helper elements and types for certain CLR types schema representation.

Posted Jun 18 2006, 10:08 AM by kirill-gavrylyuk