This is something I ran into tonight while testing a few things which I thought other people might be aware of. If you're creating arbitrary message parts in a multi-part message in a BizTalk orchestration, and you're loading your part's data from a Stream directly, be aware that you can only use a MemoryStream and not any arbitrary Stream implementation.


This will happen either if you call LoadFrom() on your new XLANGPart instance or if you call AddPart() to the XLANGMessage instance with the constructor that takes both an object (the stream you want to load the message to) and a string (the part name) overload.


The problem lies in that both of these methods eventually call into the GenericLoadFrom() method in the Microsoft.XLANGs.Core.Part class, which basically does the following:


else if (source is Stream)


{


   value1 = new Value(source as Stream);


}


Which in turns calls this:


public Value(Stream s)


{


   if ( s == null )


   {


      throw new ArgumentNullException("s");


   }


   if ( !s.CanRead )


   {


      throw new ArgumentException("!s.CanRead");


   }


   if ( !(s is ICloneable) )


   {


      MemoryStream stream1 = s as MemoryStream;


      if ( stream1 == null )


      {


         throw new ArgumentNullException("s as MemoryStream");


      }


      byte[] buffer1 = stream1.GetBuffer();


      s = new ReadOnlyBufferStream(buffer1, (int)stream1.Length);


   }


   IRefCountedStreamFactory factory1 = new ReplayableStreamStreamFactory(s);


   this._assignRewriter(factory1);


}


 


As you can see, the problem arises if you have an arbitrary Stream that is not clonable or is not a MemoryStream, such as a lowly FileStream.


Tomas Restrepo

Software developer located in Colombia. Sr. PFE at Microsoft.