Over the years while working with .NET and NIEM I’ve run into a few kinks that require a setting tweak or an extra step to get it to work. 

.NET General

Choices for working with NIEM Xml (From the .NET Base class library.  There are third-party tools out there to assist as well):

Linq

  • System.Xml.Linq.XDocument, XElement, et. al. are not Serializable.  You cannot accept them as an input or return them as an output from services (Web/Sockets/Queues/etc) or any place that will attempt serialize them.
  • With Linq to Xml using XDocument or XElement changes the axis for your query.  If you parse a string to an XDocument your query starts at the root node.  If you parse a string into XElement your query starts from the first element in the Xml and not at the root.  Typically this isn’t a major hassle but the problem is that you may not notice it until you actually try a query at run time and do not get the results you expect. (See also Unit Testing!)

WCF

  • MaxReceivedMessageSize and MaxStringContentLength will be your enemies.  Every service you write, you will want to change those values from the default 65536 otherwise callers to your service will get a nice Fault Exception when they send you a message larger than that.
  • MaxItemsInObjectGraph will need to be adjusted if you are going to be serializing large objects using direct serialization or you try to return a very large list or array of objects.
  • MaxArrayLength should be adjusted in conjunction with MaxItemsInObjectGraph.  Typically you’ll need to adjust both.  You’ll use arrays more if you do any interop work between .NET and other technology stacks as Arrays are typically safer for Xml serialization.
  • For interop scenarios your best bets are to stay with simple data types supported by Xml Schema (Xsd): String, Date, Integer, and arrays thereof.  Adding specific .NET types like GUID, List<T>, etc will add additional schemas to your service contract and may cause issues with other technology stacks.
  • Data Contract Serialization (the default) gives you less control over your Xml messages.  Xml Serialization gives you fine grain control and is usually a better fit for working with NIEM in WCF.

Visual Studio

  • Visual Studio solutions only allow an Xml Namespace to be defined once.  If you try to import two XSDs that define the same namespace you will not be able to leverage the Xml Intellisense and document validations provided by the Xml parser in Visual studio.  This really comes into play if you attempt to import LEXS digest and payload schemas in the same solution.
  • Typically I would create a project in a VS Solution just for Xml Schemas.  You can use a class library and it is not necessary to reference it from other projects.  Schemas are used at the solution level, even when the schemas are in a project.
  • While navigating an Xml document if you type an opening bracket, select an Xml element, and press tab twice studio will create an Xml fragment with all the required elements.

These are certainly not all the tips, but its a start.  Feel free to contact me if you have some to share or have any questions!