none
Creation of proxy code from WSDL using svcutil.exe: Getting "CODEGEN: Generating message contract since..." RRS feed

  • Question

  • I am in the final stages of preparing a WSDL contract and associated .NET SDK for release to customers.  Being unfamiliar with WCF, I used wsdl.exe to generate proxy code and created a Windows Forms application as a sample for our customers.  Very recently, I found that the method I used is considered a "legacy technology" in Microsoft's eyes, and that "new development should use WCF."  After investigating a bit, I found svcutil.exe and ran my WSDL contract through it to generate C# proxy code.  When I did so, just above the definitions of each of the method classes, the tool output, e.g.,

    // CODEGEN: Generating message contract since the operation SocialSearch is neither RPC nor document wrapped.

    I've done some subsequent investigating online and found that WCF (DataContractSerializer) and svcutil.exe have some fairly strict requirements on the WSDL contract, i.e., among other things that it be in the document literal wrapped style rather than the document literal style that my WSDL is presently in.  Normally I wouldn't have a problem altering my WSDL to be WCF compliant, but this page 's explanation of the difference between document literal and document literal wrapped (particularly where it shows the SOAP messages being sent out over the wire) has me thinking that I'd need to significantly change our server's output in order to be in line with the document literal wrapped style.

    My questions are the following:  (1) If I leave the WSDL as-is, will a developer needing to use WCF be able to use our WSDL contract (and our server, for that matter, since it seems to me that it doesn't generate document literal wrapped output)?  I.e., svcutil DOES generate proxy code, it just has the warning above for each method class; would those method classes still be using WCF to communicate?  If not, is this a problem for WCF developers?  (2)  If I did want to make our WSDL contract DCS compliant, is my understanding correct that I'd have to alter our server's output, or is there something I'm missing here?  (3)  If I did make our WSDL contract DCS compliant and alter our server's output as necessary to use document literal wrapped style, would that create any possible problems for developers using other platforms, e.g., Java?

    At present, our server expects the following SOAP message for incoming queries:

    <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
      <soap:Body>
       <veris:SocialSearchQuery xmlns:veris="https://secure.veris.net/">
         (child elements...)
       </veris:SocialSearchQuery>
      </soap:Body>
    </soap:Envelope>
    

    and returns the following response:

    <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
      <soap:Body>
       <veris:SocialSearchResponse xmlns:veris="https://secure.veris.net/">
         (child elements...)
       </veris:SocialSearchResponse>
      </soap:Body>
    </soap:Envelope>
    
    I'm more than happy to post the WSDL if that would be helpful.  Any insight anyone could share with me on this would be greatly appreciated.

    Dan Jonsen

    Thursday, March 17, 2011 1:44 AM

Answers

  • That message is just a warning, WCF/Java/whatever should be able to communicate with your service without problems.  The main tradeoff here is the generated WCF client OM might be more cumbersome (you'll have to deal with creating wrapper objects directly) than if it was doc lit wrapped. 

    This blog post has rundown of the wsdl changes necessary to make it wrapped, these would necessitate changes to the messages on the wire:

    http://pzf.fremantle.org/2007/05/handlign.html

    Other platforms shouldn't have any problems with a doc lit wrapped service.

    Hope this helps.

    • Marked as answer by Dan Jonsen Wednesday, March 23, 2011 4:25 PM
    Thursday, March 17, 2011 4:59 PM
    Moderator

All replies

  • That message is just a warning, WCF/Java/whatever should be able to communicate with your service without problems.  The main tradeoff here is the generated WCF client OM might be more cumbersome (you'll have to deal with creating wrapper objects directly) than if it was doc lit wrapped. 

    This blog post has rundown of the wsdl changes necessary to make it wrapped, these would necessitate changes to the messages on the wire:

    http://pzf.fremantle.org/2007/05/handlign.html

    Other platforms shouldn't have any problems with a doc lit wrapped service.

    Hope this helps.

    • Marked as answer by Dan Jonsen Wednesday, March 23, 2011 4:25 PM
    Thursday, March 17, 2011 4:59 PM
    Moderator
  • Thank you very much for the reply.  I went through the article you linked and made several changes to my WSDL until the original warning no longer appeared.  Now, however, I get the following for each of the four method classes:

      public interface SocialSearch
      {
        // CODEGEN: Parameter 'ErrorText' requires additional schema information that cannot be captured using the parameter mode.
        // The specific attribute is 'System.Xml.Serialization.XmlElementAttribute'.
        [System.ServiceModel.OperationContractAttribute(Action="cgi-bin/VerisSocialSearchServer", ReplyAction="*")]
        [System.ServiceModel.XmlSerializerFormatAttribute()]
        [return: System.ServiceModel.MessageParameterAttribute(Name="ErrorText")]
        secure.veris.net.SocialSearchResponse SocialSearch(secure.veris.net.SocialSearchRequest request);
      }
    
    

    "ErrorText" is the name of the first child element/data member of the secure.veris.net.SocialSearchResponse element/class.  Relevant sections of the WSDL include

    <?xml version="1.0" encoding="UTF-8"?>
    <definitions 
    xmlns="http://schemas.xmlsoap.org/wsdl/" 
    xmlns:veris="https://secure.veris.net/" 
    xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" 
    name="VerisServices" 
    targetNamespace="https://secure.veris.net/"
    elementFormDefault="qualified">
    	<types>
    		<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:veris="https://secure.veris.net/" targetNamespace="https://secure.veris.net/">
    			<xs:element name="SocialSearch" type="veris:SocialSearchQueryType" nillable="true"/>
    			<xs:element name="SocialSearchResponse" type="veris:SocialSearchResponseType" nillable="true"/>
    			<xs:complexType name="SocialSearchResponseType">
    				<xs:sequence>
    					<xs:element name="ErrorText" type="xs:string" minOccurs="0" maxOccurs="unbounded" nillable="true"/>
    					<xs:element name="AdvisoryText" type="xs:string" minOccurs="0" maxOccurs="unbounded" nillable="true"/>
    					<xs:element name="ErrorNumber" type="xs:integer" maxOccurs="unbounded" nillable="true"/>
    					<xs:element name="Comment" type="xs:string" minOccurs="0" maxOccurs="unbounded" nillable="true"/>
    					<xs:element name="QueryParameters" type="veris:SocialSearchQueryType" nillable="true"/>
    					<xs:element name="ServerInfo" type="veris:ServerInfoType" nillable="true"/>
    					<xs:element name="Record" type="veris:SocialSearchResponseRecordType" minOccurs="0" maxOccurs="unbounded" nillable="true"/>
    				</xs:sequence>
    			</xs:complexType>
    			...
    		</xs:schema>
    	</types>
    	<message name="SocialSearchRequest">
    		<part element="veris:SocialSearch" name="parameters" />
    	</message>
    	<message name="SocialSearchResponse">
    		<part element="veris:SocialSearchResponse" name="parameters" />
    	</message>
    	<portType name="SocialSearch">
    		<operation name="SocialSearch">
    			<input message="veris:SocialSearchRequest" />
    			<output message="veris:SocialSearchResponse" />
    		</operation>
    	</portType>
    	<binding name="SocialSearchServiceSOAP" type="veris:SocialSearch">
    		<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" />
    		<operation name="SocialSearch">
    			<soap:operation soapAction="cgi-bin/VerisSocialSearchServer" style="document"/>
    			<input>
    				<soap:body use="literal" />
    			</input>
    			<output>
    				<soap:body use="literal" />
    			</output>
    		</operation>
    	</binding>
    	<service name="SocialSearch">
    		<port binding="veris:SocialSearchServiceSOAP" name="SocialSearchServiceSOAP">
    			<soap:address location="https://secure.veris.net/cgi-bin/VerisSocialSearchServer" />
    		</port>
    	</service>
    	...
    </definitions>
    
    
    Any hints on what might be going wrong now would be greatly appreciated.

    Saturday, March 19, 2011 11:10 PM
  • A quick way to diagnose issues like this is to use svcutil.exe on the wsdl with the /dconly switch.  In this case with a similar schema I get message saying maxOccurs must be 1.  There's a discussion of this issue in this thread:

    http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/74092328-8b81-41e4-b081-d985e17877e0/

    Hope this helps.

    • Marked as answer by Yi-Lun Luo Wednesday, March 23, 2011 9:09 AM
    • Unmarked as answer by Dan Jonsen Wednesday, March 23, 2011 4:25 PM
    Monday, March 21, 2011 11:54 PM
    Moderator
  • Once again, thank you very much for the reply.  One final quick question if I may:  On a list of conditions I found somewhere that must be satisfied for a WSDL to be DCS compliant, it says that ALL elements must be namespace-qualified, not just the outermost.  At the moment, I have "http://schemas.xmlsoap.org/wsdl/" set as the default namespace in the WSDL (see above).  If I were to change it so that MY namespace ("https://secure.veris.net/") is the default (in both the "definitions" element of the WSDL and in the "schema" element of the embedded XSD), and prefix all of the items in the "http://schemas.xmlsoap.org/wsdl/" namespace with, e.g., "wsdl:", would that allow me to have all of the elements defined in MY namespace go without a prefix?

    Once again, any hints greatly appreciated.

     

    Wednesday, March 23, 2011 4:34 PM
  • Or might it be enough to simply change our messages over the wire from those listed in my original post to

    <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <soap:Body>
    < SocialSearchQuery xmlns="https://secure.veris.net/">
    (child elements...)
    </SocialSearchQuery>
    </soap:Body>
    </soap:Envelope>

    and

    <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <soap:Body>
    <SocialSearchResponse xmlns="https://secure.veris.net/">
    (child elements...)
    </SocialSearchResponse>
    </soap:Body>
    </soap:Envelope>

    i.e., to make our namespace the "default" in the opening tag of the outermost element?

     

    Wednesday, March 23, 2011 4:41 PM