As many of you know, BizTalk Server 2004 can represent messages as either XSD schemas or .NET classes.

The most common approach is to use an XSD schema. If you choose to use a .NET class to represent a message, remember that the BizTalk 2004 engine needs to be able to serialize/deserialize your message with the XML serializer.

Consider the following code (which originally appeared in a post on microsoft.public.biztalk.general):

using System;
using Microsoft.XLANGs.BaseTypes;
using System.Xml.Serialization;

namespace FastTrackObjects
{
   [Serializable]
   public class ExcelResults
   {
      public ExcelResults(int requestId, string error)
      {
         RequestId = requestId;
         Error = error;
      }

      [DistinguishedFieldAttribute()]
      public int RequestId;

      [DistinguishedFieldAttribute()]
      public string Error;
   }
}


What is wrong with that code? Well, if you build the orchestration, you will probably receive:

'FastTrackObjects.ExcelResults' must be Xml serializable to be a message part type

If you look closely, you notice that the previous class does not have a default constructor. A quick trip to serialization 101 under "XML Serialization Considerations" reveals that "a class must have a default constructor to be serialized by XmlSerializer".

At deserialization time, the XmlSerializer first creates an instance of the new object and then populates the properties and other fields. This is why a default constructor is required. BizTalk 2004 detects this fact at orchestration compilation time and prevents you from deploying an orchestration that will be unreliable due to lack of serialization.