System.ServiceModel 4.0.0.0 System.ServiceModel.MessageContractMemberAttribute System.AttributeUsage(System.AttributeTargets.Property | System.AttributeTargets.Field | System.AttributeTargets.All, Inherited=false) The attribute allows you to map fields and properties of a type marked with the attribute to SOAP message headers. The field or property can be of a simple type or a composite type that can be serialized. For information on controlling the serialization of the contents of a SOAP body without modifying the default SOAP envelope itself, see , Specifying Data Transfer in Service Contracts, and Data Contracts Overview. For more information about creating message contracts, see Using Message Contracts. The SOAP standard defines the following attributes that can exist on a header: Actor or Role (Actor in SOAP 1.1, Role in SOAP 1.2) MustUnderstand Relay The Actor or Role attribute specifies the URI of the node for which a given header is intended. The MustUnderstand attribute specifies whether the header understands the node processing. The Relay attribute specifies whether the header is to be relayed to downstream nodes. indigo1 does not perform any processing of these attributes on incoming messages, except for the MustUnderstand attribute. You can, however, read and write these attributes, even though they are not sent by default. You can set the attribute values in two ways. First, you can change the , and properties on the . (There is no Role property – set the property and Role is passed if SOAP 1.2 is used). For example: code reference: MessageHeaderAttribute#7 The second way to control these attributes is by making the desired header type the type parameter of the class and using the resulting type together with the . Then use the properties programmatically to set the SOAP attributes. For example: code reference: MessageHeaderAttribute#7 code reference: MessageHeaderAttribute#8 If both the dynamic and the static control mechanisms are used, the static settings are the default but can be overridden using the dynamic mechanism. For example: code reference: MessageHeaderAttribute#9 code reference: MessageHeaderAttribute#10 Creating repeated headers with dynamic attribute control is allowed. For example: [MessageHeaderArray] public MessageHeader<Person> documentApprovers[]; On the receiving side, reading these SOAP attributes can only be done if the generic class is used. Examine the , or properties of a header of the type to discover the attribute settings on the received message. When a message is received and then sent back, the SOAP attribute settings only roundtrip for headers of the type.

Specifies that a data member is a SOAP message header.

Constructor 4.0.0.0 To be added.

Initializes a new instance of the class.

Property 4.0.0.0 System.String To be added. For more information, see the Remarks section of for details.

Gets or sets a URI that indicates the node at which this header is targeted. Maps to the role header attribute when SOAP 1.2 is used and the actor header attribute when SOAP 1.1 is used.

Property 4.0.0.0 System.Boolean To be added. For more information, see the Remarks section of for details. It is important to remember that if the property is true in a message being sent and the application on the receiving side does not understand the header a fault is generated. Conversely, if a header with the mustUnderstand SOAP header attribute set to true is received by indigo1, it must be a part of the message contract (or must be processed by one of the indigo1 channels); otherwise, it is assumed that the header is not understood and an exception is thrown.

Specifies whether the node acting in the role must understand this header. This is mapped to the mustUnderstand SOAP header attribute.

Property 4.0.0.0 System.Boolean To be added. This property is ignored when SOAP 1.1 is used. For more information, see the Remarks section of for details.

Specifies whether this header is to be relayed to downstream nodes. This is mapped to the relay SOAP header attribute.