Parsing messages with variable length arrays of fixed length fields

I have a need to parse (and build) fixed length text based messages that may in some cases contain array fields.

Example:

PARTA LOTA 02SUBLOT1 SUBLOT2 03TEST1 RESULT1 TEST2 RESULT2 TEST3 RESULT3

If this were an object, it might use the Lot object below.

Part Number (PARTA)

Lot Number (LOTA)

An Array of 2 SubLot Objects (SUBLOT1 with quantity 150 and SUBLOT2 with Quantity 999)

An Array of 3 Test Results (TEST1 with result 1234.67890, ...)

Note that the number of array items is specified in the message.

I was hoping to use the FileHelpers library that I've seen people talking about, but it doesn't appear to support multiple array fields where there is another field specifying the quantity, and it doesn't support field types that themselves have the attribute of [FixedLengthRecord()].

This is what I would like to be able to do. Note that the field length of 10 is just an artifact of keeping this simple. Not all fields would normally be defined with the same length.

[FixedLengthRecord()]
public class Lot
{
    [FieldFixedLength(10)]
    public string PartNumber { get; set; }
    [FieldFixedL开发者_开发技巧ength(10)]
    public string LotNumber { get; set; }
    [FieldFixedLength(10)]
    public SubLot[] SubLots { get; set; }
    [FieldFixedLength(10)]
    public Test[] Tests { get; set; }
}

[FixedLengthRecord()]
public class SubLot
{
    [FieldFixedLength(10)]
    public string SubLotNumber { get; set; }
    [FieldFixedLength(10)]
    public int Quantity { get; set; }
}

[FixedLengthRecord()]
public class Test
{
    [FieldFixedLength(10)]
    public string Description { get; set; }
    [FieldFixedLength(10)]
    public double Result { get; set; }
}

Anyone have any idea if this is possible with FileHelpers? Any other ideas? I have many different message types so I would rather not manually code for each one. The attribute decoration method in FileHelpers seems like a great clean solution and I'm considering just extending it, but I want to make sure I'm not missing a better solution out there.

---

I believe that I done something very similar in the past.

The way that I tackled this issue is to use custom attributes. This allowed me to create classes and nested objects which described my data exactly as described in the specification and use custom attributes to describe the data attributes (lenght, type, padding requirements, if required etc).

I also ended up writing a custom serialization/deserialization for the classes and attributes however that was really specific to the actual application as the data was coming through a custom government protocol which also sent and received data in fixed sized chunks or packets over encrypted sockets with continuation codes etc.

Tutorials

• http://msdn.microsoft.com/en-us/library/aa288454%28v=vs.71%29.aspx
• http://www.codeproject.com/KB/cs/attributes.aspx
• http://www.devx.com/dotnet/Article/11579