I want to expose enum attributes to WCF client application, but I can only see enum values.
Here is the enum:
public enum TemplateType
{
[EnumDescription("Property Particulars")]
[EnumValue("PropertyParticulars")]
PropertyParticulars = 1,
[EnumDescription("Short Format Lists")]
[EnumValue("ShortFormatLists")]
ShortFormatLists,
[EnumDescription("Client Letters")]
[EnumValue("ClientLetters")]
ClientLetters,
[EnumDescription("Labels")]
[EnumValue("Labels")]
Labels
}
How can I expose the Description and Value attributes?
You can expose enums from a service but the attributes on an enum are not serialized when they are sent over the wire. This means that consumers of this enum will only see the enum itself and none of your attributes.
What you need to do is dress up your enum with a DataContract attribute and the values with the EnumMember attribute so that your information will be serialized, but this will only allow you to specify the underlying value of each enum value, not a description.
There is a workaround if the intention is to expose a display text for enum members, define your enum in this way in the contracts:
public enum EPaymentCycle
{
[EnumMember(Value = "Month by Month")]
Monthly,
[EnumMember(Value = "Week by Week")]
Weekly,
[EnumMember(Value = "Hour by Hour")]
Hours
}
The SvcUtils serialization produces an interesting result:
public enum EPaymentCycle : int
{
[System.Runtime.Serialization.EnumMemberAttribute(Value="Month by Month")]
MonthByMonth= 0,
[System.Runtime.Serialization.EnumMemberAttribute(Value="Week by Week")]
WeekbyWeek= 1,
[System.Runtime.Serialization.EnumMemberAttribute(Value="Hour by Hour")]
HourbyHour = 2
}
You can read the EnumMemberAttribute Value by reflection and there you got it. Also the xsd metadata file produced by svcutil serialization is as expected:
<xs:simpleType name="EPaymentCycle">
<xs:restriction base="xs:string">
<xs:enumeration value="Month by Month" />
<xs:enumeration value="Week by Week" />
<xs:enumeration value="Hour by Hour" />
</xs:restriction>
I'm not fully versed in the specs, but I doubt this kind of metadata has an equivalent representation in WSDL. Thus, this will not be visible on the client side if you generate the types in your proxy.
However, if you put all your DataContracts in a separate assembly that you reference in the client, you can reuse those types on the client side. In that case, the attributes would be visible. "Reuse types in referenced assemblies" needs to be checked for your Service Reference, but this is on by default.
Here's a short blog post about it. I'm sure there are others...
Example enum for the values of a traffic light...
[DataContract]
public enum TrafficLightType
{
[EnumMember]
Red,
[EnumMember]
Green,
[EnumMember]
Amber
}
Related
In my web service I want to get rid of the generated ArrayOf... definitions in the WSDL which are generated by calling ...service.svc?singleWsdl.
Currently the definiton looks like (and I tried all varieties using XmlArray, etc.):
[DataContract]
public class Incident {...}
[CollectionDataContract(Name = "IncidentList", ItemName = "IncidentItem")]
public class IncidentList : List<Incident>
{
public IncidentList()
: base()
{ }
public IncidentList(IEnumerable<Incident> list)
: base(list)
{ }
}
[MessageContract]
public class IncidentsResponse
{
[MessageBodyMember]
public Incident[] Incidents { get; set; }
[MessageBodyMember]
public IncidentList IncidentList { get; set; }
}
When I get the WSDL I always receive (more or less - depending on Name attributes, etc.):
<xs:element name="IncidentsResponse">
<xs:complexType><xs:sequence>
<xs:element minOccurs="0" maxOccurs="1" name="IncidentList" type="tns:ArrayOfIncident"/><xs:element minOccurs="0" maxOccurs="1" name="Incidents" type="tns:ArrayOfIncident"/>
</xs:sequence>
</xs:complexType></xs:element>
What I would really like to have is the types listed directly inside the element like
<xs:element name="IncidentsResponse">
<xs:complexType>
<Incidents><IncidentItem>...</IncidentItem><IncidentItem>...</IncidentItem> </Incidents>
<IncidentList><IncidentItem>...</IncidentItem><IncidentItem>...</IncidentItem></IncidentList>
</xs:complexType></xs:element>
So a reference to the actual data as such, not the list type (ArrayOf).
Any way to achieve this? The CollectionDataContract attribute is supposed to do the trick if I get the info right, but somehow it doesn't...
Especially as the consuming client is Java this extra indirection is hurting a bit as it bloats the code
Any ideas welcome :-)
this is intended since wcf can be used across language so it should support common types rather than only supporting .net specific type.
still if u want to generate a proxy using svcutil with list then you can create it by using the sample svcutil wsdl /ct:System.Collections.Generic.List`1 or if you are using adding service reference then there is an advanced button , Click that button and select the System.Generic.List as your Collection. This will resolve the problem.. and having the array information will not harm anything so it can be left as it is.
We have a WCF service which includes Serializable classes in a contract that has DataContract and DataMember at the root level of the service.
While trying to build a solution to isolate the problem, I came across the following:
[ServiceContract]
public interface IService1
{
[OperationContract]
CompositeType GetDataUsingDataContract();
}
[DataContract]
public class CompositeType
{
[DataMember]
public MyType MyProperty { get; set; }
}
[Serializable]
public class MyType
{
private int amount1;
[XmlElement(Form = XmlSchemaForm.Unqualified, DataType = "int", ElementName = "AmountN")]
public int Amount1
{
get
{ return amount1; }
set
{ amount1 = value; }
}
}
Gives the following xsd:
<xs:complexType name="CompositeType">
<xs:sequence>
<xs:element name="MyProperty" type="tns:MyType" nillable="true" minOccurs="0"/>
</xs:sequence>
</xs:complexType><xs:element name="CompositeType" type="tns:CompositeType" nillable="true"/>
<xs:complexType name="MyType">
<xs:sequence>
<xs:element name="amount1" type="xs:int"/>
</xs:sequence>
</xs:complexType>
<xs:element name="MyType" type="tns:MyType" nillable="true"/>
</xs:schema>
Question is: Why is the private but not the public member being serialized?
Serializers and serialization attributes are two different things.
XmlElement is attribute for XmlSerializer but it has no meaning for DataContractSerializer or for BinaryFormatter. XmlElementAttribute Class
DataContractSerializer can serialize multiple types, but it uses own serialization algorithm Link. When serializing objects marked with [Serializable],
DataContractSerializer follows default serialization pattern (serializing all members, [NonSerialized] applies). If you need more control then you can implement ISerializable for custom serialization and then you can set node names and values in serialized object Serialization .
There is also an option to implement IXmlSerializable and have full control on how serialized object will look like.
This msdn article can explain, why wcf is able to serialize your MyType:
Types Supported by the Data Contract Serializer: . . .
Types marked with the SerializableAttribute attribute. Many types
included in the .NET Framework base class library fall into this
category. The DataContractSerializer fully supports this serialization
programming model that was used by .NET Framework remoting, the
BinaryFormatter, and the SoapFormatter, including support for the
ISerializable interface.
And since wcf have no problem to serialize private fields, probably this is the reason of serializing your privet field amount1.
INO, The question is "why your property Amount1 was not serialized?" I'd try to rename it (be different from field name), remove xml attributes on it, and re-try.
This is my ABC on the server side:
<endpoint address="msmq.formatname:DIRECT=OS:.\private$\imhmsgs"
binding="msmqIntegrationBinding"
bindingConfiguration="IncomingMessageHandlerBinding"
contract="TMC.Services.Contracts.Messages.IInboundMessageHandlerService">
As soon as I do an .Open() to host the service, I get the exception:
Cannot serialize interface
XYZ.Services.Contracts.Messages.Interfaces.IMyMessage.
My IMyMessage interface:
[ServiceContract]
[ServiceKnownType(typeof(IMyMessage))]
[ServiceKnownType(typeof(ConcreteMessage))]
public interface IInboundMessageHandlerService
{
[OperationContract(IsOneWay = true, Action = "*")]
void ProcessIncomingMessage(MsmqMessage<IMyMessage> incomingMessage);
}
The implementor for that interface:
[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Multiple,
ReleaseServiceInstanceOnTransactionComplete = false)]
public class InboundMessageHandlerService : IInboundMessageHandlerService
{
[OperationBehavior(TransactionScopeRequired = true, TransactionAutoComplete = true)]
public void ProcessIncomingMessage(MsmqMessage<IMyMessage> incomingMessage)
{
}
}
The type that is being created by the client basically is a concrete class, which derives from a base class and also an interface (IMyMessage) and then places this on the MSMQ.
After some testing, if I remove the service known type attributes and just instead use say "string" instead, then it seems to open the host but faults (because the message type is not what it was expecting).
where am I going wrong?
On further testing I see that if I only specify the concrete type, it works.
This is not quite what I was expecting.
how am I able to create it so that the service can take a known interface and classes which that interface has? The idea is for the client (using the same contract and classes) to send the message as "IMyMessage" and for the WCF service to pick that up as "IMyMessage" and go ahead and find out the type of message/object it is.
How?
Your contract is an interface, but the definition within the contract must be concrete classes.
In your case it looks like you want to send over a list of things, those things could be different but they all support the same interface.
The problem is that when WCF deserialises what has been sent over the wire, it needs to deserialise it the a concrete type. If it just has an interface in the definition and 20 different types that implement that definition, it does not know what to do with it.
What you can do is have a base type that implements the interface, all your classes inherit from the base type and you use the base type in your contact.
In WCF you can define a contract using the [DataContract] and [DataMember] attributes, like this:
[DataContract]
public class Sample
{
[DataMember(EmitDefaultValue = false, IsRequired = false)]
public string Test { get; set; }
}
This article on the MSDN states that using EmitDefaultValue = false is not recommended:
However, i like to use this, because the XML that is generated using this construction is cleaner. Not specifying this setting results in:
<Sample>
<Test xsi:nil="true"/>
</Sample>
while using the setting the element is ommited when there is no value:
<Sample>
</Sample>
I'm curious to what the reasoning behind that statement is. Specifically since both snipptes of XML look equivalent to me (and both last part can be deserialized correctly for this contract).
What is the reasoning behind this statement?
The reason is at the bottom of the article that you link to. The short version is:
When the EmitDefaultValue is set to false, it is represented in the schema as an annotation specific to Windows Communication Foundation (WCF). There is no interoperable way to represent this information. In particular, the "default" attribute in the schema is not used for this purpose, the minOccurs attribute is affected only by the IsRequired setting, and the nillable attribute is affected only by the type of the data member.
The actual default value to use is not present in the schema. It is up to the receiving endpoint to appropriately interpret a missing element.
The Setup
I have a WCF service that exposes a base type (e.g. Animal) as well as a few derived types (e.g. Lion, Tiger, and Bear). Another type (e.g. Zoo) includes a property that is a collection of the base type. The base type is concrete, not abstract, so it is perfectly acceptable for the collection to contain instances of the base type and/or the derived types (in any combination). For example:
[DataContract, KnownType(typeof(Lion)),
KnownType(typeof(Tiger)), KnownType(typeof(Bear))]
public class Animal
{
[DataMember]
public string Species { get; set; }
}
[DataContract]
public class Lion : Animal { }
[DataContract]
public class Tiger : Animal { }
[DataContract]
public class Bear : Animal { }
[DataContract]
public class Zoo
{
[DataMember]
public List<Animal> Animals { get; set; }
}
One of my service operations accepts this type as its parameter, like so:
[ServiceContract]
public interface IZooService
{
[OperationContract]
void SetZoo(Zoo zoo);
}
All of this is well and good, and the emitted WSDL looks perfectly fine to me. It contains all of the types and correctly indicates that the derived types inherit from the base type. So, I should be able to call my service using a SOAP message such as the following:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:z="http://zoo.org">
<soapenv:Header/>
<soapenv:Body>
<z:SetZoo>
<z:Zoo>
<z:Animals>
<z:Animal>
<z:Species>Crocodile</z:Species>
</z:Animal>
<z:Tiger>
<z:Species>Bengal</z:Species>
</z:Tiger>
<z:Bear>
<z:Species>Grizzly</z:Species>
</z:Bear>
</z:Animals>
</z:Zoo>
</z:SetZoo>
</soapenv:Body>
</soapenv:Envelope>
In the above SOAP message, the Animals collection contains one instance of the base Animal type, an instance of the derived Tiger type, and an instance of the derived Bear type. WCF should be able to deserialize this message successfully.
The Problem
WCF doesn't throw any exceptions when it receives the above message. Instead, it simply ignores the derived types (Tiger and Bear) completely, and by the time deserialized message is passed to my code, the Animals collection only contains the Crocodile entry, since it is of the base type.
So, I guess I have two questions... First, why is WCF not deserializing the derived type instances in the collection. And second, since WCF obviously doesn't like something about this SOAP message, why isn't it throwing an exception? This sort of silent failure is very troubling.
Okay... I figured out the problem. It turns out that the SOAP syntax for this scenario requires a little extra work to get right. Because the Animals collection is defined as an array of Animal types, all of the child elements in the SOAP message need to be elements, even if they are actually instances of a derived type. The actual instance type is defined by the "type" attribute, which is part of the XMLSchema-instance namespace. So, my SOAP message should have looked like this:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns:z="http://zoo.org">
<soapenv:Header/>
<soapenv:Body>
<z:SetZoo>
<z:Zoo>
<z:Animals>
<z:Animal>
<z:Species>Crocodile</z:Species>
</z:Animal>
<z:Animal i:type="z:Tiger">
<z:Species>Bengal</z:Species>
</z:Animal>
<z:Animal i:type="z:Bear">
<z:Species>Grizzly</z:Species>
</z:Animal>
</z:Animals>
</z:Zoo>
</z:SetZoo>
</soapenv:Body>
</soapenv:Envelope>
Of course, that still doesn't address my other concern, which is that the WCF deserializer should throw an exception if it doesn't understand the SOAP message. It shouldn't just silently ignore parts of the message!