I think most of you prefer to implement service port type first while try to build a wcf service. That is ok, however, did you ever take the final stub class in your consideration, in the meanwhile you are coding a wcf service?
As known, we can use ?WSDL to get wsdl displayed in IE. Most of time, we will get the following WSDL:
<wsdl:import namespace=http://services/ location=http://XXXX/Service.svc?wsdl=wsdl0 />
<wsdl:types />
Unfortunately, Schemas and Messages are missing. It will be a big impact to generate proxy class by wsdl.exe or access by SOAP UI.
At then, we have to query like http://XXXX/Service.svc?wsdl=wsdl0, http://XXXX/Service.svc?xsd=xsdn (n starts from 0) to get schemas and Messages.
If this service is large enough, you will find it will be a tough job.
Ok, what should we do now? I think we have two approaches:
1, facilitate a static wsdl file before developing services. and configure <system.serviceModel> section like the following:
<services>
<!-- Replace the parameters below for your service implementation -->
<service name="ServicePortType" behaviorConfiguration="ServiceBehavior" >
<endpoint address="" binding="basicHttpBinding" bindingNamespace=http://service/ contract="IServicePortType"
/>
</
service ></
services ><behaviors>
<serviceBehaviors>
<behavior name="ServiceBehavior" >
<serviceMetadata httpGetEnabled="true" externalMetadataLocation="..\service.wsdl"/>
</
behavior ></
serviceBehaviors ></
behaviors >Ok, job is done. Next time , if you attempt to link http://XXXX/Service.svc?wsdl, you wil get a flat wsdl.
2, Develop a custom behavior to support Inlined XSD.