Hello,

We are working on a (C# .NET6) project where we generate XML files using Liquid XML Objects generated classes. What probably makes our solution somewhat unusual is that we want to populate the instances of the Liquid generated classes using reflection.

While doing this, we have run into an issue where the serialized XML file isn't deterministic, and items in sequences get written out of order. We have ensured that the generated code uses the "Conformant" Generation Model, but the problem persists through that.

In order to debug the issue, we have created a simplified project that reproduces the error, and ran it on multiple machines (mix of Windows and Ubuntu Server), and the results differ on the different machines and execution modes (debug in visual studio, no debugging in visual studio, running the deployed app).

The debug project uses an "operation log" that has been generated to replicate behaviour from our real project. Using that, the debug project uses reflection methods to fill Liquid XML Objects with data and once done, it's serialized out to a file and the result is validated against the XSD schema.

The same process is done multiple times in a loop, and output files that do not validate against the schema are stored and this is marked on the console output. While the code is identical for every iteration of the loop, the outputs differ. Most executions we do will start to produce invalid XML files almost immediately (within the first 10 iterations), but one platform (a newly installed VM running Ubuntu Server) generated around 120 correct files after which it devolved into roughly 50% failure rate.

We have uploaded the project to Github if someone wants to reproduce the error on their end. It can be found here:

github.com/graz-se/LiquidXML-example

As a side-note, the problem appears to be triggered by the use of reflection. The project above also generates code for a non-reflection variant of the same process, which does not appear to generate invalid XML files if used. If absolutely necessary, generating code and compiling it in runtime could be a way to get around the issue but we would like to avoid that if possible (if nothing else, that's a big performance hit).