Biztalk set WCF MessageHeaders in Biztalk message assignment - wcf

I'm trying to set the MessageHeader of a message that my Biztalk orchestration is sending to WCF. The Message Contract looks as follows in the WCF project.
[MessageContract(IsWrapped = true, WrapperName = "PerformTransformationRequestWrapper", WrapperNamespace="http://www.iasreo.com/integration/servicetypes")]
public class PerformTransformationRequest
{
[MessageHeader(Namespace = "http://www.iasreo.com/integration/servicetypes")]
public string Version { get; set; }
/// <summary>
///
/// </summary>
[MessageHeader(Namespace = "http://www.iasreo.com/integration/servicetypes", MustUnderstand = true)]
public TransformType TransformType { get; set; }
/// <summary>
///
/// </summary>
[MessageBodyMember(Namespace = "http://www.iasreo.com/integration/servicetypes")]
public System.IO.Stream Payload { get; set; }
}
TransformType.cs
[DataContract(Namespace = "http://www.iasreo.com/integration/servicetypes")]
public enum TransformType
{
/// <summary>
/// Transform to Excel
/// </summary>
[EnumMember]
ExcelTransform = 1,
/// <summary>
/// Transform to PDF
/// </summary>
[EnumMember]
PDFTransform = 2
}
I'm creating the message to send to Biztalk in a Message Assignment shape and that code looks as follows:
xmlDoc = new System.Xml.XmlDocument();
xmlDoc.LoadXml(#"<ns0:PerformTransformationRequestWrapper xmlns:ns0=""http://www.iasreo.com/integration/servicetypes""><ns0:Payload>GpM7</ns0:Payload></ns0:PerformTransformationRequestWrapper>");
PerformTransformationRequest = xmlDoc;
xpath(PerformTransformationRequest, "/*[local-name()='PerformTransformationRequestWrapper' and namespace-uri()='http://www.iasreo.com/integration/servicetypes']/*[local-name()='Payload']") = System.Convert.ToBase64String(System.Text.Encoding.ASCII.GetBytes(Input.OuterXml));
How can I set the Version and TransformType that MessageHeaders in the WCF MessageContract?

You can set the promoted WCF.OutboundCustomHeaders property of the outgoing message
OutboundMessage(WCF.OuboundCustomHeaders) = "...";
You need to supply the complete WCF Header string as the parameter.
This http://bencode.net/biztalk-custom-wcf-behaviour might be of use to you.

Related

WCFFaultException with an error status code is always being returned back to the client as 202 accepted

In our application, if required, we are throwing a fault exception as follows:
throw new WebFaultException(new RequestFaultInfo(errorMessage), System.Net.HttpStatusCode.BadRequest);
The RequestFaultInfo class is as follows:
/// <summary>
/// Fault information used as the detail of a web service request failure.
/// </summary>
[DataContract]
public class RequestFaultInfo
{
#region Constants
/// <summary>
/// Summary fault reason.
/// </summary>
public const string Reason = "Request failure";
#endregion
private string m_errorDescription;
#region Object Lifetime
/// <summary>
/// Constructor specifying the login error description.
/// </summary>
/// <param name="errorDescription">Request error description.</param>
/// <exception cref="ArgumentException">errorDescription is null or empty.</exception>
public RequestFaultInfo(string errorDescription)
{
if (String.IsNullOrEmpty(errorDescription))
{
throw new ArgumentException("errorDescription cannot be null or empty", "errorDescription");
}
m_errorDescription = errorDescription;
}
#endregion
#region Properties
/// <summary>
/// Login error description.
/// </summary>
[DataMember]
public string ErrorDescription
{
get { return m_errorDescription; }
private set { m_errorDescription = value; }
}
#endregion
However, the client is always getting the status code 202 (Accepted). In this case the client is Postman on the same server.
Has anyone got any ideas why this is happening?

Akka.net Hyperion IgnoringDataMember

I use akka.net in a cluster schema. (n) processing nodes, with currently 1 lighthouse.
One of the package that navigate throught network expose langage information.
/// <summary>
/// Define scored a suite of token info
/// </summary>
/// <seealso cref="Hammer.Immutable.ImmutableObject" />
[DataContract]
public sealed class TokenSuite : ImmutableObject, IIdItem
{
#region Ctor
/// <summary>
/// Initializes a new instance of the <see cref="TokenSuite"/> class.
/// </summary>
public TokenSuite(Guid id, string langCode)
: base(id, langCode)
{
this.Id = id;
this.LangCode = langCode;
if (!string.IsNullOrEmpty(langCode))
LangInfo = CultureInfo.GetCultureInfoByIetfLanguageTag(langCode);
}
#endregion
#region Properties
/// <summary>
/// Gets the identifier.
/// </summary>
[DataMember]
public Guid Id { get; }
/// <summary>
/// Gets the main language code.
/// </summary>
[DataMember]
public string LangCode { get; }
/// <summary>
/// Gets the lang information.
/// </summary>
[IgnoreDataMember]
public CultureInfo LangInfo { get; }
#endregion
In local no problem but when it pass through the network (serialized) i got this issue on the lighthouse :
Reading the error it seems coming from the CultureInfo Object but it is flag to be ignored in the serializations.
I use Akka version 1.3.5, Hyperion 0.9.8, Akka.Serialization.Hyperion 1.3.2-beta54.
I try to serialize locally and it works :
var serializer = Context.System.Serialization.FindSerializerForType(typeof(TokenSuite));
var data = serializer.ToBinary(result);
var rtoObjectBack = serializer.FromBinary<TokenSuite>(data);
Any idea ?
Hyperion does not make any use of data contract attributes. This also means that [IgnoreDataMember] won't be taken into account.
Probably it fails when trying to deserialize a CultureInfo object, you've provided. You can always try to convert that to string, and resolve after deserialization.

Unable to deserialize CSLA request in soap message sent by WCF (C#)

I am learning WCF so my apologies if my terminology is off here and there.
I am trying to deserialize a soap message that was sent with WCF and captured by Fiddler and I keep getting this error message: "The data at the root level is invalid. Line 1, position 1."
The WCF service is setup with the following code:
// Set up WcfProxy DataPortal service url
Csla.DataPortalClient.WcfProxy.DefaultUrl = appRootUrl + "WcfSilverlightPortal.svc";
// Set up WcfProxy Binding
System.ServiceModel.BasicHttpBinding largeBinding = new System.ServiceModel.BasicHttpBinding();
largeBinding.MaxReceivedMessageSize = 20000000;
largeBinding.MaxBufferSize = 20000000;
largeBinding.OpenTimeout = new TimeSpan(0, 10, 0);
largeBinding.ReceiveTimeout = new TimeSpan(0, 10, 0);
largeBinding.CloseTimeout = new TimeSpan(0, 10, 0);
largeBinding.SendTimeout = new TimeSpan(0, 10, 0);
largeBinding.Name = "BasicHttpBinding_IWcfPortal";
Csla.DataPortalClient.WcfProxy.DefaultBinding = largeBinding;
The soap message captured in Fiddler is as follows:
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Body>
<Fetch xmlns="http://ws.lhotka.net/WcfDataPortal">
<request xmlns:d4p1="http://schemas.datacontract.org/2004/07/Csla.Server.Hosts.Silverlight" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
<d4p1:ClientContext>QBhBcnJheU9mU2VyaWFsaXphdGlvbkluZm8IQWh0dHA6Ly9zY2hlbWFzLmRhdGFjb250cmFjdC5vcmcvMjAwNC8wNy9Dc2xhLlNlcmlhbGl6YXRpb24uTW9iaWxlCQFpKWh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlQBFTZXJpYWxpemF0aW9uSW5mb0AIQ2hpbGRyZW4JAWE5aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS8yMDAzLzEwL1NlcmlhbGl6YXRpb24vQXJyYXlzAUALUmVmZXJlbmNlSWSDQAhUeXBlTmFtZZhlQ3NsYS5Db3JlLkNvbnRleHREaWN0aW9uYXJ5LCBDc2xhLCBWZXJzaW9uPTQuMy4xMy4wLCBDdWx0dXJlPW5ldXRyYWwsIFB1YmxpY0tleVRva2VuPTkzYmU1ZmRjMDkzZTRjMzABQAZWYWx1ZXMJAWE5aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS8yMDAzLzEwL1NlcmlhbGl6YXRpb24vQXJyYXlzAQEB</d4p1:ClientContext>
<d4p1:ClientCulture>en-US</d4p1:ClientCulture>
<d4p1:ClientUICulture>en-US</d4p1:ClientUICulture>
<d4p1:CriteriaData i:nil="true" />
<d4p1:GlobalContext>QBhBcnJheU9mU2VyaWFsaXphdGlvbkluZm8IQWh0dHA6Ly9zY2hlbWFzLmRhdGFjb250cmFjdC5vcmcvMjAwNC8wNy9Dc2xhLlNlcmlhbGl6YXRpb24uTW9iaWxlCQFpKWh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlQBFTZXJpYWxpemF0aW9uSW5mb0AIQ2hpbGRyZW4JAWE5aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS8yMDAzLzEwL1NlcmlhbGl6YXRpb24vQXJyYXlzAUALUmVmZXJlbmNlSWSDQAhUeXBlTmFtZZhlQ3NsYS5Db3JlLkNvbnRleHREaWN0aW9uYXJ5LCBDc2xhLCBWZXJzaW9uPTQuMy4xMy4wLCBDdWx0dXJlPW5ldXRyYWwsIFB1YmxpY0tleVRva2VuPTkzYmU1ZmRjMDkzZTRjMzABQAZWYWx1ZXMJAWE5aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS8yMDAzLzEwL1NlcmlhbGl6YXRpb24vQXJyYXlzAQEB</d4p1:GlobalContext>
<d4p1:Principal>QBhBcnJheU9mU2VyaWFsaXphdGlvbkluZm8IQWh0dHA6Ly9zY2hlbWFzLmRhdGFjb250cmFjdC5vcmcvMjAwNC8wNy9Dc2xhLlNlcmlhbGl6YXRpb24uTW9iaWxlCQFpKWh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlQBFTZXJpYWxpemF0aW9uSW5mb0AIQ2hpbGRyZW4JAWE5aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS8yMDAzLzEwL1NlcmlhbGl6YXRpb24vQXJyYXlzAUALUmVmZXJlbmNlSWSDQAhUeXBlTmFtZZhwQ3NsYS5TZWN1cml0eS5VbmF1dGhlbnRpY2F0ZWRQcmluY2lwYWwsIENzbGEsIFZlcnNpb249NC4zLjEzLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49OTNiZTVmZGMwOTNlNGMzMAFABlZhbHVlcwkBYTlodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tLzIwMDMvMTAvU2VyaWFsaXphdGlvbi9BcnJheXNeM0tleVZhbHVlT2ZzdHJpbmdTZXJpYWxpemF0aW9uSW5mby5GaWVsZERhdGFPem9adkxybV4DS2V5mRZDc2xhUHJpbmNpcGFsLklkZW50aXR5XgVWYWx1ZUAMRW51bVR5cGVOYW1lLgNuaWyGAUAHSXNEaXJ0eYVABVZhbHVlLgR0eXBlmA5iOmJhc2U2NEJpbmFyeQkBYiBodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYaCNCUAYQXJyYXlPZlNlcmlhbGl6YXRpb25JbmZvCEFodHRwOi8vc2NoZW1hcy5kYXRhY29udHJhY3Qub3JnLzIwMDQvMDcvQ3NsYS5TZXJpYWxpemF0aW9uLk1vYmlsZQkBaSlodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYS1pbnN0YW5jZUARU2VyaWFsaXphdGlvbkluZm9ACENoaWxkcmVuCQFhOWh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vMjAwMy8xMC9TZXJpYWxpemF0aW9uL0FycmF5c14zS2V5VmFsdWVPZnN0cmluZ1NlcmlhbGl6YXRpb25JbmZvLkNoaWxkRGF0YU96b1p2THJtXgNLZXmZDV9maWVsZE1hbmFnZXJeBVZhbHVlQAdJc0RpcnR5hUALUmVmZXJlbmNlSWSJAgEBAUALUmVmZXJlbmNlSWSDQAhUeXBlTmFtZZhvQ3NsYS5TZWN1cml0eS5VbmF1dGhlbnRpY2F0ZWRJZGVudGl0eSwgQ3NsYSwgVmVyc2lvbj00LjMuMTMuMCwgQ3VsdHVyZT1uZXV0cmFsLCBQdWJsaWNLZXlUb2tlbj05M2JlNWZkYzA5M2U0YzMwAUAGVmFsdWVzCQFhOWh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vMjAwMy8xMC9TZXJpYWxpemF0aW9uL0FycmF5cwEBQBFTZXJpYWxpemF0aW9uSW5mb0AIQ2hpbGRyZW4JAWE5aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS8yMDAzLzEwL1NlcmlhbGl6YXRpb24vQXJyYXlzXjNLZXlWYWx1ZU9mc3RyaW5nU2VyaWFsaXphdGlvbkluZm8uQ2hpbGREYXRhT3pvWnZMcm1eA0tleZkFUm9sZXNeBVZhbHVlQAdJc0RpcnR5hUALUmVmZXJlbmNlSWSJAwEBAUALUmVmZXJlbmNlSWSJAkAIVHlwZU5hbWWYcUNzbGEuQ29yZS5GaWVsZE1hbmFnZXIuRmllbGREYXRhTWFuYWdlciwgQ3NsYSwgVmVyc2lvbj00LjMuMTMuMCwgQ3VsdHVyZT1uZXV0cmFsLCBQdWJsaWNLZXlUb2tlbj05M2JlNWZkYzA5M2U0YzMwAUAGVmFsdWVzCQFhOWh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vMjAwMy8xMC9TZXJpYWxpemF0aW9uL0FycmF5c14zS2V5VmFsdWVPZnN0cmluZ1NlcmlhbGl6YXRpb25JbmZvLkZpZWxkRGF0YU96b1p2THJtXgNLZXmZE19idXNpbmVzc09iamVjdFR5cGVeBVZhbHVlQAxFbnVtVHlwZU5hbWUuA25pbIYBQAdJc0RpcnR5hUAFVmFsdWUuBHR5cGWYCGI6c3RyaW5nCQFiIGh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hmG9Dc2xhLlNlY3VyaXR5LlVuYXV0aGVudGljYXRlZElkZW50aXR5LCBDc2xhLCBWZXJzaW9uPTQuMy4xMy4wLCBDdWx0dXJlPW5ldXRyYWwsIFB1YmxpY0tleVRva2VuPTkzYmU1ZmRjMDkzZTRjMzABAQFeM0tleVZhbHVlT2ZzdHJpbmdTZXJpYWxpemF0aW9uSW5mby5GaWVsZERhdGFPem9adkxybV4DS2V5mRJBdXRoZW50aWNhdGlvblR5cGVeBVZhbHVlQAxFbnVtVHlwZU5hbWUuA25pbIYBQAdJc0RpcnR5hUAFVmFsdWUuBHR5cGWYCGI6c3RyaW5nCQFiIGh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hAQEBXjNLZXlWYWx1ZU9mc3RyaW5nU2VyaWFsaXphdGlvbkluZm8uRmllbGREYXRhT3pvWnZMcm1eA0tleZkPSXNBdXRoZW50aWNhdGVkXgVWYWx1ZUAMRW51bVR5cGVOYW1lLgNuaWyGAUAHSXNEaXJ0eYVABVZhbHVlLgR0eXBlmAliOmJvb2xlYW4JAWIgaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWGFAQFeM0tleVZhbHVlT2ZzdHJpbmdTZXJpYWxpemF0aW9uSW5mby5GaWVsZERhdGFPem9adkxybV4DS2V5mQROYW1lXgVWYWx1ZUAMRW51bVR5cGVOYW1lLgNuaWyGAUAHSXNEaXJ0eYVABVZhbHVlLgR0eXBlmAhiOnN0cmluZwkBYiBodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYQEBAQEBQBFTZXJpYWxpemF0aW9uSW5mb0AIQ2hpbGRyZW4JAWE5aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS8yMDAzLzEwL1NlcmlhbGl6YXRpb24vQXJyYXlzAUALUmVmZXJlbmNlSWSJA0AIVHlwZU5hbWWYvkNzbGEuQ29yZS5Nb2JpbGVMaXN0YDFbW1N5c3RlbS5TdHJpbmcsIG1zY29ybGliLCBWZXJzaW9uPTUuMC41LjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49N2NlYzg1ZDdiZWE3Nzk4ZV1dLCBDc2xhLCBWZXJzaW9uPTQuMy4xMy4wLCBDdWx0dXJlPW5ldXRyYWwsIFB1YmxpY0tleVRva2VuPTkzYmU1ZmRjMDkzZTRjMzABQAZWYWx1ZXMJAWE5aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS8yMDAzLzEwL1NlcmlhbGl6YXRpb24vQXJyYXlzXjNLZXlWYWx1ZU9mc3RyaW5nU2VyaWFsaXphdGlvbkluZm8uRmllbGREYXRhT3pvWnZMcm1eA0tleZkFJGxpc3ReBVZhbHVlQAxFbnVtVHlwZU5hbWUuA25pbIYBQAdJc0RpcnR5hUAFVmFsdWUuBHR5cGWYDmI6YmFzZTY0QmluYXJ5CQFiIGh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hnoc8QXJyYXlPZnN0cmluZyB4bWxuczppPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYS1pbnN0YW5jZSIgeG1sbnM9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vMjAwMy8xMC9TZXJpYWxpemF0aW9uL0FycmF5cyIgLz4BAQEBAZ8BAQEBAQEB</d4p1:Principal>
<d4p1:TypeName>Competition.Domain.Entities.SchoolSummaryList, Competition.Domain.Csla, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null</d4p1:TypeName>
</request>
</Fetch>
</s:Body>
</s:Envelope>
I am trying to deserialize this to an object of type Csla.Server.Hosts.Silverlight.CriteriaRequest
The code for this class looks like this:
//-----------------------------------------------------------------------
// <copyright file="CriteriaRequest.cs" company="Marimer LLC">
// Copyright (c) Marimer LLC. All rights reserved.
// Website: http://www.lhotka.net/cslanet/
// </copyright>
// <summary>Message sent to the Silverlight</summary>
//-----------------------------------------------------------------------
using System;
using System.Runtime.Serialization;
using System.Security.Principal;
using Csla.Core;
namespace Csla.Server.Hosts.Silverlight
{
/// <summary>
/// Message sent to the Silverlight
/// WCF data portal.
/// </summary>
[DataContract]
public class CriteriaRequest
{
/// <summary>
/// Assembly qualified name of the
/// business object type to create.
/// </summary>
[DataMember]
public string TypeName { get; set; }
/// <summary>
/// Serialized data for the criteria object.
/// </summary>
[DataMember]
public byte[] CriteriaData { get; set; }
/// <summary>
/// Serialized data for the principal object.
/// </summary>
[DataMember]
public byte[] Principal { get; set; }
/// <summary>
/// Serialized data for the global context object.
/// </summary>
[DataMember]
public byte[] GlobalContext { get; set; }
/// <summary>
/// Serialized data for the client context object.
/// </summary>
[DataMember]
public byte[] ClientContext { get; set; }
/// <summary>
/// Serialized client culture.
/// </summary>
/// <value>The client culture.</value>
[DataMember]
public string ClientCulture { get; set; }
/// <summary>
/// Serialized client UI culture.
/// </summary>
/// <value>The client UI culture.</value>
[DataMember]
public string ClientUICulture { get; set; }
}
}
I have tried grabbing each of the three xml elements 'Body', 'Fetch' and 'request' from the soap message and storing them as an XElement variable named 'element' and running the code below:
DataContractSerializer dcs = new DataContractSerializer(typeof(CriteriaRequest));
MemoryStream ms = new MemoryStream(System.Text.Encoding.UTF8.GetBytes(element.Value));
ms.Seek(0, SeekOrigin.Begin);
XmlDictionaryReader reader = XmlDictionaryReader.CreateTextReader(ms, Encoding.UTF8, new XmlDictionaryReaderQuotas(), null);
CriteriaRequest fr = (CriteriaRequest)dcs.ReadObject(reader);
In every case it has failed to deserialize the object and I am out of ideas.
I think I have provided all the relavent information but if anything else would help please let me know and I will provide it.
Thanks.
You can't use the more simplistic serializers to directly serialize a CSLA .NET object graph. Serializers such as XmlSerializer, JsonSerializer, and the various DataContractSerializer variations aren't sophisticated enough to completely clone and object graph, and so they aren't supported by CSLA.
Only the BinaryFormatter, NetDataContractSerializer, and MobileFormatter are supported.
Odds are you are trying to expose your business objects directly as a service interface. That's a poor architectural choice, and one I'd never choose to support or encourage anyone to do. You might find the XML Services FAQ page useful.

Silverlight is not liking my WCF MessageContract. Why?

I am attempting to upload a file through a Silverlight client using the following MessageContract:
[MessageContract]
public class CategoryClientFileTransferMC : IDisposable
{
/// <summary>
/// CategoryID - Category identity.
/// </summary>
[MessageHeader(MustUnderstand = true)]
public int CategoryID;
/// <summary>
/// ID - File identifier.
/// </summary>
[MessageHeader(MustUnderstand = true)]
public string ID;
/// <summary>
/// Length - File length in bytes.
/// </summary>
[MessageHeader(MustUnderstand = true)]
public long Length;
/// <summary>
/// FileByteStream - File stream.
/// </summary>
[MessageBodyMember(Order = 1)]
public Stream FileByteStream;
/// <summary>
/// Dispose the contract.
/// </summary>
public void Dispose()
{
if (FileByteStream != null)
{
FileByteStream.Close();
FileByteStream = null;
}
}
}
My problem is that the generated operation method on the client only takes a single argument; a byte array called FileByteStream. In other (non-Silverlight) clients I've created it asks for the MemberHeader fields as well. Without specifying these headers, the server has no idea what to do with the file. How can I set these headers when I call the operation?
Also, is there a better way to upload a file from a Silverlight client? This has been a huge headache.
Thanks.
The Silverlight subset of the WCF client does not support the [MessageHeader] attribute. You can still set message headers, but it's not as straightforward as in other platforms. Basically, you'll need to set the headers using the operation context, prior to making the call, like in the example below:
var client = new SilverlightReference1.MyClient();
using (new OperationContextScope(client.InnerChannel))
{
string contractNamespace = "http://tempuri.org/";
OperationContext.Current.OutgoingMessageHeaders.Add(
MessageHeader.CreateHeader("CategoryId", contractNamespace, 1));
OperationContext.Current.OutgoingMessageHeaders.Add(
MessageHeader.CreateHeader("ID", contractNamespace, "abc123"));
OperationContext.Current.OutgoingMessageHeaders.Add(
MessageHeader.CreateHeader("Length", contractNamespace, 123456L));
client.UploadFile(myFileContents);
}
Where contractNamespace is the XML namespace for the message header fields (IIRC they default to the same as the service contract). You can use Fiddler and something like the WCF Test Client to see which namespace is used there.

WCF web service not working Due to type of Data contract

When i am testing my WCF web service through "WcfTestClient", it is showing
"this operation is not supported in wcf test client because it uses type VINDescription"
Where VINDescriptionis a DataContract, which is consist of datamembers of type :
"int, string, ArrayList"
It seems WCF web service is not supporting ArrayList?
Please suggest how can i fix this?
Here is a code snippet of DataContract :
[DataContract]
public class VINDescription
{
#region Private Members
private int _cylinders = 0;
private string _msrp = string.Empty;
private ArrayList _interior = new ArrayList();
private string[][] _showOptionalEquipment = new string[][] { };
#endregion
#region Public Data Members
/// <summary>
/// Stores the number of cylinders of a decoded vehicle.
/// </summary>
[DataMember]
public int Cylinders
{
get
{
return _cylinders;
}
set
{
_cylinders = value;
}
}
/// <summary>
/// Stores the MSRP cost of a decoded vehicle.
/// </summary>
[DataMember]
public string MSRP
{
get
{
return _msrp;
}
set
{
_msrp = value;
}
}
/// <summary>
/// Stores the interior values of a decoded vehicle.
/// </summary>
[DataMember]
public ArrayList Interior
{
get
{
_interior.Sort();
return _interior;
}
set
{
_interior = value;
}
}
/// <summary>
/// To store the data for show optional equipments.
/// </summary>
[DataMember]
public string[][] ShowOptionalEquipment
{
get
{
return _showOptionalEquipment;
}
set
{
_showOptionalEquipment = value;
}
}
The way I understand it, WCF actually supports your data contract, but the WCF Test Client tool does not support everything that WCF itself supports, hence the error. Not sure if it's because of ArrayList, string[][], or something else, but in any case it seems to be a tool limitation, not a framework limitation.