During serialization, property-get code is called for property data members to get the value of the properties to be serialized. During deserialization, an uninitialized object is first created, without calling any constructors on the type. Then all data members are deserialized. During deserialization, property-set code is called for property data members to set the properties to the value being deserialized.
For a data contract to be valid, it must be possible to serialize all of its data members. Generic types are handled in exactly the same way as non-generic types. There are no special requirements for generic parameters. For example, consider the following type.
This type is serializable whether the type used for the generic type parameter T is serializable or not. Because it must be possible to serialize all data members, the following type is serializable only if the generic type parameter is also serializable, as shown in the following code. Feedback will be sent to Microsoft: By pressing the submit button, your feedback will be used to improve Microsoft products and services. Privacy policy. Skip to main content.
This is a keyword in C. This keyword is then attached to the Tutorial class. If you don't mention this attribute, you will get an error when you try to serialize the class. Next is the definition of the class which will be serialized. What is WCF C? Using WCF, you can send data as asynchronous messages from one service endpoint to another.
A service endpoint can be part of a continuously available service hosted by IIS, or it can be a service hosted in an application. What is fault contract in WCF? This class has two forms: FaultException: to send an untyped fault back to the caller. What is DataMember in C? Data Member attribute. Data Member are the fields or properties of your Data Contract class. You must specify [DataMember] attribute on the property or the field of your Data Contract class to identify it as a Data Member.
A datacontract is a formal agreement between a client and service that abstractly describes the data to be exchanged. In WCF, the most common way of serialization is to make the type with the datacontract attribute and each member as datamember.
Creating a basic DataContract and DataMember. What is message contract in WCF? A message contract is used to control the structure of a message body and serialization process. By use of a Message Contract we can customize the parameters sent using a SOAP message between the client and the server. What is a data member C?
Data Members. While an empty reply message is described by having a void return type and no output or reference parameters. For example:. In this approach, the request message is represented with a single type, and the reply message is also represented with a single type. While you can use a data contract for this purpose, the recommended approach is to use a message contract. Also message contracts allow you to exercise more control over resultant messages by deciding which pieces of information should be in the message body and which should be in the message headers.
The following example illustrates:. A Stream -derived class can also be used in an operation contract or as a message-contract body-member must be the only member in this case. The following illustrates how to use Stream to describe messages:. See Faults for more details. You may want to use a base in an operation-contract or A message-contract, and then use a derived type when actually invoking the operation. When the default DataContractSerializer is in use, there are some aspects of the serialization process that may be controlled by applying the [ServiceBehaviorAttribute] attribute to the service.
Specifically, the [MaxItemsInObjectGraph] property may be used to set the quota that limits the maximum number of objects the DataContractSerializer deserializes:. There are two behaviors available in WCF, the DataContractSerializerOperationBehavior and the XmlSerializerOperationBehavior that are automatically plugged in depending on which serializer is in use for a particular operation. Because these behaviors are applied automatically, you normally do not have to be aware of these behaviors.
The first two properties have the same meaning as discussed in the previous section. The DataContractSurrogate property can be used to enable data contract surrogates, which are a powerful mechanism to customize and extend the serialization process. The other approach in which you can customize the way data is serialized is to control MaxItemsInObjectGraph and IgnoreExtensionDataObject through configuration, using the DataContractSerializer endpoint or service behavior, as shown in the following example.
User-defined types must define a data contract for them to be serializable. This is done by applying the [DataContract] attribute to classes, structs and enums. Bitmap GetPicture System. PurchaseOrder is a user-defined type, and thus requires a data contract. WCF is case-sensitive to both namespaces and names of data contracts and data members. The following example, along with comments, illustrate some of the basic concepts relating to data contract names:.
There are special rules for determining data contract names for generic types. This is to avoid data contract name collisions between two closed generics of the same generic type. By default, the data contract name for a generic type is the name of the type, followed by the string "Of", followed by the data contract names of the generic parameters, followed by a hash computed using the data contract namespaces of the generic parameters.
When all of the generic parameters are primitive types, the hash is omitted. If the data contract names generated for generic types are unacceptable, you can use the Name property of the DataContractAttribute attribute to specify a different way to generate names. For example, the preceding generic Drawing type could have been declared as. Types sent between a client and a service do not necessarily have to exist on the receiving end.
The only requirement is that data contracts of both types are equivalent:. For data contracts to be equivalent, they must have the same namespace and name. Additionally, each data member on one side must have an equivalent data member on the other side.
For data members to be equivalent, they must have the same name. Additionally, they must represent the same type of data, i. For example, the following data contracts are equivalent — both data contracts have the same name, and each data member in class Customer have an equivalent data member in class Person :. In some applications, you may need to know the order in which data from the various data members is sent or is expected to be received such as the order in which data appears in the serialized XML.
Sometimes it may be necessary to change this order. Note the following basic rules regarding ordering of data members:. If a data contract type is a part of an inheritance hierarchy, data members of its base types are first in the order. Next in order are any data members that have the Order property of the [DataMember] attribute set; these are ordered by the value of the Order property first and then alphabetically if there is more than one member of a certain Order value. Order values may be skipped.
The [KnownType] attribute is used to inform the deserialization engine about types that should be considered during the actual deserialization. When passing parameters and return values between a client and a service, both endpoints share fully all of the data contracts of the data to be transmitted.
However, there are circumstances in which this is not the case:. The declared type for the information to be transmitted is an interface, as opposed to a class, structure, or enumeration. Therefore, it cannot be known, in advance, which type that implements the interface is actually sent.
The declared type for the information to be transmitted is Object. Because every type inherits from Object, and it cannot be known in advance which type is actually sent. Some types, including. NET Framework types, have members that fall under one of the preceding three categories.
For example, Hashtable uses Object to store the actual objects in the hash table. When serializing these types, the receiving end again cannot determine in advance the data contract for these members. When data arrives at a receiving endpoint, the WCF runtime attempts to deserialize the data into an instance of some CLR type. The type that is instantiated for deserialization is chosen by first inspecting the incoming message to determine the data contract. The deserialization engine then attempts to find a CLR type that implements a data contract compatible with the message contents.
The set of candidate types that the deserialization engine considers during this process is referred to as the deserializer's set of "known types. One way to let the deserialization engine know about a type is by using the [KnownType].
The attribute can only be applied to whole data contract types. The attribute is applied to an "outer type" that can be a class or a structure.
In its simplest usage, applying the attribute simply specifies a type as a "known type. Primitive types and certain types treated as primitives for example, DateTime and XmlElement are always "known" and never have to be added through the [KnownType] attribute. However, arrays of primitive types have to be added explicitly. For example, consider these three classes with an inheritance relationship:. The following DeptInfo class can be serialized, but cannot be deserialized if the person member is set to either a Manager or Developer class, because the deserialization engine does not recognize any types with data contract names " Manager " or " Developer ":.
Note that there are additional ways to add known types: You can also add types to the KnownTypeCollection , accessed through the KnownTypes property of the DataContractSerializer. Additionally, known types may be added through a configuration file. This is useful when you do not have control over the type that requires known types for proper deserialization, such as when using third-party type libraries with Windows Communication Foundation WCF.
Changes to a data contract can be breaking or nonbreaking. When a data contract is changed in a nonbreaking way, both the old and the new versions of the data contract can still communicate. On the other hand, a breaking change prevents communication in one or both directions. Changes to a type that do not affect how it is transmitted and received are nonbreaking. For example, you can change the name of a field in a nonbreaking way if you then set the Name property of the [DataMember] to the older version name.
For example, consider version 1 of this data contract:. Changing the order of data members by using the Order property of the DataMemberAttribute. Changing the data contract of a data member. For example, changing the type of a data member from an integer to a string, or from a type with a data contract named "Customer" to a type with a data contract named "Person.
In most cases, adding or removing a data member is a non-breaking change, unless you require strict schema validity. When a type with an extra field is deserialized into a type with a missing field, the extra information is ignored. When a type with a missing field is deserialized into a type with an extra field, the extra field is left at its default value, usually zero or null.
A data member may be marked required by setting the IsRequired property of the [DataMember] to true. If required data is missing while deserializing, an exception is thrown instead of setting the data member to its default value. Adding a required data member is a breaking change.
That is, the newer type can still be sent to endpoints with the older type, but not the other way around. Removing a data member that was marked as required in any prior version is also a breaking change.
Changing the IsRequired property value from true to false is not breaking, but changing it from false to true may be breaking if any prior versions of the type do not have the data member in question. The DataContractSerializer translates between. The following sections explain how this serializer works.
When serializing. NET Framework objects, the serializer understands a variety of serialization programming models, including the new Data Contract model. NET type names as part of the serialized data.
It is used when exactly the same types are shared on the serializing and the deserializing ends. A serializer created for a certain root type cannot be used to serialize or deserialize another type, unless the type is derived from the root type.
0コメント