SubSonic - Serializing Classes with Nullable types and collections?

Using SubSonic v2.x: The first issue is the error discussed here:

Server Error in '/......' Application. Cannot serialize member '.....' of type System.Nullable

I'm not sure where to place the code in my DAL from this post to get this working. I tried placing it in one of the partial classes I created for a table, but no go.

Another fix for this is to add:

generateNullableProperties="false"

However this isn't an option in the intelisense in my providers section of my subsonic config for my DAL. (It is supposed to go on the DAL config or the app's config?)

I managed to get around this

[XmlElement(Type = typeof(TblReceiptLineItem))]

to the following code:

public partial class TblReceipt
{
    // no need to override any existing methods or properties as we 
    // are simply adding one

    //[XmlElement]

    // specifying the types of objects to be contained within the arraylist
    [XmlElement(Type = typeof(TblReceiptLineItem))]
    public ArrayList ReceiptLineItemsArr = new ArrayList();
    public string UserPhoneNumber;
    public string UserCardNumber;
}

... and only because I changed a nullable field in TblReceiptLineI开发者_运维百科tem to not nullable.

However, now the error is:

Unable to cast object of type 'System.Collections.ArrayList' to type 'DAL.TblReceiptLineItem'.

So I'm thinking it hasn't even gotten to the Nullable type error yet and not liking the cast.

So what is the best way to serialize an object that contains a collection with 1..* elements of a custom type (that is SubSonic-friendly). And what is the best way to de-serialize this data?

The second (not yet) issue, is I have an object with a collection of objects in one of its members. Do I have to serialized the collection within the object before serializing the entire object, or will the XmlSerializer take care of all of this?

Thank you.

== UPDATE ==

So it looks like the problem was actually solved with my little fix above. I had some other erroneous code that was causing the second error.

However, my code now fully serializes the main object with the array list of objects inside.

So the fix was to add the type before declaration:

[XmlElement(Type = typeof(TblReceiptLineItem))]

However better ways of accomplishing this (or others) are welcome.

Issue 1 - I dont know

Issue 2 - It depends on the collection and the objects. Some collections (ex Dictionary) are not serializable. If the collection is serializable, then yes, the entire object graph should get serialized. Of course, that may get a wrench thrown in by lazy loading too.

EDIT: Any reason why the usual wouldn't work for you?

    [Serializable]
    public partial class tblReciept
    {
        public List<TblReceiptLineItem> ReceiptLineItemsArr { get; set; }
    }

    [Serializable]
    public class TblReceiptLineItem
    {
        public int ItemId { get; set; }
    }

    class Program
    {
        static void Main( string[] args )
        {
            var reciept = new tblReciept
            {
                ReceiptLineItemsArr = new List<TblReceiptLineItem>
                {
                    new TblReceiptLineItem { ItemId = 1 },
                    new TblReceiptLineItem { ItemId = 222 },
                    new TblReceiptLineItem { ItemId = 156 }
                }
            };

            XmlSerializer s = new XmlSerializer( typeof( tblReciept ) );
            TextWriter w = new StreamWriter( @"c:\list.xml" );
            s.Serialize( w, reciept );
            w.Close( );
        }

    }


// output 
<?xml version="1.0" encoding="utf-8"?>
<tblReciept xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <ReceiptLineItemsArr>
    <TblReceiptLineItem>
      <ItemId>1</ItemId>
    </TblReceiptLineItem>
    <TblReceiptLineItem>
      <ItemId>222</ItemId>
    </TblReceiptLineItem>
    <TblReceiptLineItem>
      <ItemId>156</ItemId>
    </TblReceiptLineItem>
  </ReceiptLineItemsArr>
</tblReciept>

Glad you got it fixed - serializing nullable types crashes and burns in C# 2.0 in general - but if it works, hurrah!