InfoPath Dev

Environment: InfoPath 2003 SP1, .NET 1.1 (C#)

I'm struggling for a solution where several InfoPath forms are deserialized to C# classes, their content combined into another c# class and then serialized to another XML form to be edited in Infopath again. The issue is that the serialized data in the TotalForm(XML) is of a different order than the XSD of the TotalForm template dictates.
cust code
Form1 XML + Form2 XML ---------> TotalForm XML

TotalForm is a pretty large form that has data from Form1 and Form2 combined in a specific way. I created C# classes for all forms using the XSD from the respective InfoPath templates using XSD.exe (.NET 1.1). Custom C# code combines the data from Form1 and Form2 into a TotalForm class instance. By deserializing the TotalForm instance I was expecting XML that was editable by InfoPath.
InfoPath however considers the XML invalid because fields are in random order in the XML and not in the order the XSD dictates. Serialization is failing to generate fields in the correct order (order of the fields in the generated class)

(SUBNOTE:: serializing and deserializing has its own issue with DateTime, null string fields and InfoPath processing instructions, but that's not the issue here)

I took the (de)serialization road because I thought that would be the fastest and safest way to process InfoPath data in a 'typesafe' manner and safeguard/detect Form Template changes. It is however turning out to be a nightmare. I overcame all struggles except generating XML for TotalForm that is editable in InfoPath.

The TotalForm is particularly large and I would not want to type XmlDocument code by hand or use XSLT trickery. I forsee too much problems when the Form Template would change.

XSD.exe and XmlSerialization in .NET 2.0 support order, but simply fail the serialize the fields in the correct order (bug?).

Does anybody have a suggestion how to create the TotalForm XML according to the InfoPaths Template XSD using C#?

Hi VictorV and welcome to our forum,
You said: "InfoPath however considers the XML invalid because fields are in random order in the XML". This is a key statement. What order is expected? Are you using xsd:any? Why not use InfoPath's Import functionality for this scenario instead of code? It's more flexible with XSL and could be less maintenance longterm (but uses XSLT trickery).

We need to understand why it is failing first and then figure out if it's a bug in InfoPath or requires a more more loosely defined schema.

Thanks for replying, Patrick.

When the .NET framework is serializing a class instance, the fields of the class seem to be outputted in random order. I took a look at the generated XmlSerializerWriter for the class and the code confirms the random order of class' fields in the XML output.

InfoPath refuses to load the serialized XML because it does not conform to the XML schema of the InfoPath template. The schema dictates a sequence of fields, validates the loading XML form against the schema and loading the XML fails. The fields in the (via XSD.exe generated) class have the exact order of the sequence, but a serialized instance shows fields in a different order. The order expected is the order of fields the schema dictates (and is also the order of the fields in the class generated by XSD.exe)

I think Microsoft tried to fix things in .NET 2.0 by adding an 'Order' field to the XML attributes in a generated class ("XSD.exe /order ..."), but an initial test showed me that .NET 2.0 XML serialize output shows again a random order of fields in the XML.

Back to your suggestion about importing in InfoPath. I'm not sure what you mean by that.

'TotalForm' is a pretty large form, combining data from severial other forms. Combining data is performed in C# code by first deserializing the source forms XML, creating a TotalForm class instance, filling fields and serializing the instance to XML.
'TotalForm' is an InfoPath template and the serialized XML for 'TotalForm' should conform to the template's schema in order for InfoPath to be able to load the XML. It's not a InfoPath bug, but a validation error by the schema.

XmlSerialization of the .NET framework however changes the field's order in de XML.

Perhaps I should abandon serialization of a TotalForm class instance and look for another way to create the TotalForm's XML....

I posted a solution in http://www.infopathdev.com/forums/22008/ShowThread.aspx#22008