KevinBurton

I have an object that on the server looks has the following property:

Code Snippet

[System.Xml.Serialization.XmlElementAttribute("Available", typeof(bool))]

[System.Xml.Serialization.XmlElementAttribute("Quantity", typeof(string), DataType="nonNegativeInteger")]

public object Item {

get {

return this.itemField;

}

set {

this.itemField = value;

}

}

When svcutil gets a hold of it to generate proxy classes I get:

Code Snippet

[System.Runtime.Serialization.DataMemberAttribute(IsRequired=true)]

public object itemField

{

get

{

return this.itemFieldField;

}

set

{

this.itemFieldField = value;

}

}

I would like to have a single public property 'Item' (no lowercase, no 'Field' suffix)and a backing private field of itemField. In other words take one of the 'Field" suffixes off of the property and the field. Is this possible

Kevin



Re: Windows Communication Foundation (Indigo) Svcutil name mangling?

ChiomaOs - MSFT

Is the container of this property DataContract or Serializable

If it is DataContract, is itemField marked with the DataMember attribute

Otherwise, if it is Serializable, is itemField public

Thanks,

~Chioma





Re: Windows Communication Foundation (Indigo) Svcutil name mangling?

KevinBurton

The container (the parent class) is Serializable. It was generated using the XSD tool. The itemField is private but the property, Item is public. The messages that pass this object back in the response are currently DataContract.

Kevin





Re: Windows Communication Foundation (Indigo) Svcutil name mangling?

ChiomaOs - MSFT

Are you using svcutil.exe to generate the code or xsd.exe The title of your post indicates svcutil.exe, but your last response indicates that you generated the code with xsd.exe.

In any case, could you post your .wsdl and .xsd files You can dummy up sections of those files if you don't want to post the real thing. I'd like to take a closer look.

Thanks,

~Chioma





Re: Windows Communication Foundation (Indigo) Svcutil name mangling?

KevinBurton

I use XSD to generate classes that are returned by WCF messages. So I am using SVCUTIL to generate the proxy on the client and XSD to generate the classes that are contained in the messages that are sent. For example:

Code Snippet

[MessageContract()]

public sealed class AmazonInventoryFeedResponseType : MessageResponseBaseType

{

private Inventory[] _InventoryFields;

[MessageBodyMember]

public Inventory[] Inventory

{

get

{

return this._InventoryFields;

}

set

{

this._InventoryFields = value;

}

}

}

The Inventory class definition is generated using XSD and a group of schema files (.xsd). The message that is sent is the container for this class. This seems to kind of work. I have two problems now.

1) The proxy that is generated (using svcutil) mangles the name of the array. The client code looks like:

Code Snippet

///

[System.CodeDom.Compiler.GeneratedCodeAttribute("svcutil", "3.0.4506.30")]

[System.SerializableAttribute()]

[System.Diagnostics.DebuggerStepThroughAttribute()]

[System.ComponentModel.DesignerCategoryAttribute("code")]

[System.Xml.Serialization.XmlTypeAttribute(Namespace="http://Buyseasons.WebServices.BsiAmazonServices.ServiceContracts/2006/12")]

public partial class AmazonInventoryFeedResponseType : MessageResponseBaseType

{

private ArrayOfInventoryInventory[] inventoryField;

///

[System.Xml.Serialization.XmlArrayAttribute(Order=0)]

[System.Xml.Serialization.XmlArrayItemAttribute("Inventory")]

public ArrayOfInventoryInventory[] Inventory

{

get

{

return this.inventoryField;

}

set

{

this.inventoryField = value;

}

}

}

As you can see what was Inventory[] on the server is ArrayOfInventoryInventory[] on the generated client proxy. That is problem one.

2) The second problem that is perhaps more severe is that the serialization or deserialization is not happening. I get no errors. I checked at the last point as the server returns from the method and all of the array values are filled in just fine. I look on the client and the values are all null or some default value. The length of the array is OK on the client. The array length on the server and the client match up just fine. Just that each element doesn't seem to be filled in by the time it reaches the client. This may be just another symptom of the first problem since the server and client don't seem to agree on the name of the array.

I have included the WSDL that is generated below.

Thank you for your help.

Kevin

Code Snippet
< xml version="1.0" encoding="utf-8" >
- <wsdl:definitions name="BsiAmazonServices" targetNamespace="http://tempuri.org/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns="http://tempuri.org/" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:i0="http://Buyseasons.WebServices.BsiAmazonServices.ServiceContracts/2006/12" xmlns:wsap="http://schemas.xmlsoap.org/ws/2004/08/addressing/policy" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:msc="http://schemas.microsoft.com/ws/2005/12/wsdl/contract" xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl" xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/" xmlns:wsa10="http://www.w3.org/2005/08/addressing" xmlns:wsx="http://schemas.xmlsoap.org/ws/2004/09/mex">
- <wsp:Policy wsu:Id="WSHttpBinding_IBsiAmazonServices_policy">
- <wsp:ExactlyOne>
- <wsp:All>
- <sp:SymmetricBinding xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
- <wsp:Policy>
- <sp:ProtectionToken>
- <wsp:Policy>
- <sp:SecureConversationToken sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
- <wsp:Policy>
<sp:RequireDerivedKeys />
- <sp:BootstrapPolicy>
- <wsp:Policy>
- <sp:SignedParts>
<sp:Body />
<sp:Header Name="To" Namespace="http://www.w3.org/2005/08/addressing" />
<sp:Header Name="From" Namespace="http://www.w3.org/2005/08/addressing" />
<sp:Header Name="FaultTo" Namespace="http://www.w3.org/2005/08/addressing" />
<sp:Header Name="ReplyTo" Namespace="http://www.w3.org/2005/08/addressing" />
<sp:Header Name="MessageID" Namespace="http://www.w3.org/2005/08/addressing" />
<sp:Header Name="RelatesTo" Namespace="http://www.w3.org/2005/08/addressing" />
<sp:Header Name="Action" Namespace="http://www.w3.org/2005/08/addressing" />
</sp:SignedParts>
- <sp:EncryptedParts>
<sp:Body />
</sp:EncryptedParts>
- <sp:SymmetricBinding>
- <wsp:Policy>
- <sp:ProtectionToken>
- <wsp:Policy>
- <sp:SpnegoContextToken sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
- <wsp:Policy>
<sp:RequireDerivedKeys />
</wsp:Policy>
</sp:SpnegoContextToken>
</wsp:Policy>
</sp:ProtectionToken>
- <sp:AlgorithmSuite>
- <wsp:Policy>
<sp:Basic256 />
</wsp:Policy>
</sp:AlgorithmSuite>
- <sp:Layout>
- <wsp:Policy>
<sp:Strict />
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp />
<sp:EncryptSignature />
<sp:OnlySignEntireHeadersAndBody />
</wsp:Policy>
</sp:SymmetricBinding>
- <sp:Wss11>
- <wsp:Policy>
<sp:MustSupportRefKeyIdentifier />
<sp:MustSupportRefIssuerSerial />
<sp:MustSupportRefThumbprint />
<sp:MustSupportRefEncryptedKey />
</wsp:Policy>
</sp:Wss11>
- <sp:Trust10>
- <wsp:Policy>
<sp:MustSupportIssuedTokens />
<sp:RequireClientEntropy />
<sp:RequireServerEntropy />
</wsp:Policy>
</sp:Trust10>
</wsp:Policy>
</sp:BootstrapPolicy>
</wsp:Policy>
</sp:SecureConversationToken>
</wsp:Policy>
</sp:ProtectionToken>
- <sp:AlgorithmSuite>
- <wsp:Policy>
<sp:Basic256 />
</wsp:Policy>
</sp:AlgorithmSuite>
- <sp:Layout>
- <wsp:Policy>
<sp:Strict />
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp />
<sp:EncryptSignature />
<sp:OnlySignEntireHeadersAndBody />
</wsp:Policy>
</sp:SymmetricBinding>
- <sp:Wss11 xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
- <wsp:Policy>
<sp:MustSupportRefKeyIdentifier />
<sp:MustSupportRefIssuerSerial />
<sp:MustSupportRefThumbprint />
<sp:MustSupportRefEncryptedKey />
</wsp:Policy>
</sp:Wss11>
- <sp:Trust10 xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
- <wsp:Policy>
<sp:MustSupportIssuedTokens />
<sp:RequireClientEntropy />
<sp:RequireServerEntropy />
</wsp:Policy>
</sp:Trust10>
<wsaw:UsingAddressing />
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
- <wsp:Policy wsu:Id="WSHttpBinding_IBsiAmazonServices_AmazonFeedDataMessage_Input_policy">
- <wsp:ExactlyOne>
- <wsp:All>
- <sp:SignedParts xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<sp:Body />
<sp:Header Name="To" Namespace="http://www.w3.org/2005/08/addressing" />
<sp:Header Name="From" Namespace="http://www.w3.org/2005/08/addressing" />
<sp:Header Name="FaultTo" Namespace="http://www.w3.org/2005/08/addressing" />
<sp:Header Name="ReplyTo" Namespace="http://www.w3.org/2005/08/addressing" />
<sp:Header Name="MessageID" Namespace="http://www.w3.org/2005/08/addressing" />
<sp:Header Name="RelatesTo" Namespace="http://www.w3.org/2005/08/addressing" />
<sp:Header Name="Action" Namespace="http://www.w3.org/2005/08/addressing" />
</sp:SignedParts>
- <sp:EncryptedParts xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<sp:Body />
</sp:EncryptedParts>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
- <wsp:Policy wsu:Id="WSHttpBinding_IBsiAmazonServices_AmazonFeedDataMessage_output_policy">
- <wsp:ExactlyOne>
- <wsp:All>
- <sp:SignedParts xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<sp:Body />
<sp:Header Name="To" Namespace="http://www.w3.org/2005/08/addressing" />
<sp:Header Name="From" Namespace="http://www.w3.org/2005/08/addressing" />
<sp:Header Name="FaultTo" Namespace="http://www.w3.org/2005/08/addressing" />
<sp:Header Name="ReplyTo" Namespace="http://www.w3.org/2005/08/addressing" />
<sp:Header Name="MessageID" Namespace="http://www.w3.org/2005/08/addressing" />
<sp:Header Name="RelatesTo" Namespace="http://www.w3.org/2005/08/addressing" />
<sp:Header Name="Action" Namespace="http://www.w3.org/2005/08/addressing" />
</sp:SignedParts>
- <sp:EncryptedParts xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<sp:Body />
</sp:EncryptedParts>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
<wsdl:import namespace="http://Buyseasons.WebServices.BsiAmazonServices.ServiceContracts/2006/12" location="http://developer03.asgard.buyseasons.com/Buyseasons/AmazonServices/BsiAmazonServices.svc wsdl=wsdl0" />
<wsdl:types />
- <wsdl:binding name="WSHttpBinding_IBsiAmazonServices" type="i0:IBsiAmazonServices">
<wsp:PolicyReference URI="#WSHttpBinding_IBsiAmazonServices_policy" />
<soap12:binding transport="http://schemas.xmlsoap.org/soap/http" />
- <wsdl:operation name="AmazonFeedDataMessage">
<soap12:operation soapAction="AmazonFeedDataMessage" style="document" />
- <wsdl:input name="MessageRequests">
<wsp:PolicyReference URI="#WSHttpBinding_IBsiAmazonServices_AmazonFeedDataMessage_Input_policy" />
<soap12:body use="literal" />
</wsdl:input>
- <wsdl:output name="MessageResponses">
<wsp:PolicyReference URI="#WSHttpBinding_IBsiAmazonServices_AmazonFeedDataMessage_output_policy" />
<soap12:body use="literal" />
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
- <wsdl:service name="BsiAmazonServices">
- <wsdl:port name="WSHttpBinding_IBsiAmazonServices" binding="tns:WSHttpBinding_IBsiAmazonServices">
<soap12:address location="http://developer03.asgard.buyseasons.com/Buyseasons/AmazonServices/BsiAmazonServices.svc" />
- <wsa10:EndpointReference>
<wsa10:Address>http://developer03.asgard.buyseasons.com/Buyseasons/AmazonServices/BsiAmazonServices.svc</wsa10:Address>
- <Identity xmlns="http://schemas.xmlsoap.org/ws/2006/02/addressingidentity">
<Upn>kevinb@ASGARD.BUYSEASONS.COM</Upn>
</Identity>
</wsa10:EndpointReference>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>





Re: Windows Communication Foundation (Indigo) Svcutil name mangling?

KevinBurton

I tried writing out the message using the XmlSerializer just before it returned.

Code Snippet

< xml version="1.0" encoding="utf-8" >

<MessageResponses xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<Responses>

<MessageResponseBaseType xsi:type="AmazonInventoryFeedResponseType">

<Inventory>

<Inventory>

<SKU>21412-139542</SKU>

<Quantity>301</Quantity>

</Inventory>

. . . .

This is what I want. I have truncated the output but it seems OK. The biggest problem now is that the object on the client end is not being filled in. All of these fields are empty but the count of "Inventory" items is OK. Is there a way to see what is received on the client end (raw XML) Maybe from that I can see what the name mangling is doing to me. Somehow the serialization or deserialization of this object isn't working. My guess is it has something to do with SVCUTIL and building the client proxy.

Kevin





Re: Windows Communication Foundation (Indigo) Svcutil name mangling?

ChiomaOs - MSFT

You could generate your classes using svcutil. This should take care of the name mangling that you are concerned about. Is there any particular reason you chose to use xsd.exe instead of svcutil to generate the types

As far as seeing what is received on the client end, you could configure message logging. The attached link explains how to accomplish this.

Thanks,

~Chioma





Re: Windows Communication Foundation (Indigo) Svcutil name mangling?

KevinBurton

The reason(s) for choosing XSD over SVCUTIL were:

1) When I fed the XSDs to SVCUTIL I received errors on the class generation plus the suggestion in the error to use XSD.

2) There were various constructs in these schema files that don't seem to be supported by SVCUTIL (choice I rember being one of them).

3) The classes generated by XSD were easily understood and it seems that names picked for the classes made sense.

Remember I only generated the simple classes using XSD. The message contains arrays of those types which is my construct and I can control both the name and the custom attributes that decorate those contructs. For example, one of the classes that I generated using XSD is a class called ProductImage. In the message that I am asking SVCUTIL to generate a proxy for I have something like:

ProductImage[] Images;

SVCUTIL is turning this into

ArrayOfProductImageProductImage[] Images

(I have the [] right). With the definition of 'ArrayOfProductImageProductImage' closely matching the class 'ProductImage' that was generated from the XSD tool. It seems unnecessary for SVCUTIL to turn 'ProductImage' into 'ArrayOfProductImageProductImage'. Actually XSD doesn't do exactly what I want either as when I serialize the object I get something like:

<ProductImage>

<ProductImage>

<Field1>test1</Field1>

<Field2>test2</Field2>

....

</ProductImage>

....

</ProductImage>

As I recall there is some attribute that I can decorate the array with so there is only one level of <ProductImage>. But that is another topic. I just want SVCUTIL not to mangle the name and perhaps the deserialization will work then.

I will try your suggestions for client logging. I have server logging turned on. I didn't know the same thing could be applied to the client. Thank you. Any other suggestions would be very welcome.

Kevin





Re: Windows Communication Foundation (Indigo) Svcutil name mangling?

Mohammad Makarechian - MSFT

Hello,

In order to repro the issue and/or for us to understand your scenario better, it'd be quite helpful if you could post the following:

  • Imported WSDL -- the posted WSDL is missing the definition of the messages used by the operations
  • XSD that define the types used by the messages in the WSDL -- probably the most important data
  • Server-side definition of type 'Inventory' or 'ProductImage' -- helps us see what causes the nested array type generation on the client side

Thanks.