views:

187

answers:

1

This question may be very similar to my one, but I cannot see the answer I need in it. I have a class, called CASM, that has a List<Action>. I want to serialize this class (using the BinaryFormatter or something similar). This class and all classes referenced in the Actions have got correct [Serializable] and [NonSerializable] attributes.

The problem comes when serialization is attempted - it gives this error:

Type 'CASM.CASM+<>c__DisplayClass2c' in Assembly 'CASM, Version=1.0.0.0,
Culture=neutral, PublicKeyToken=null' is not marked as serializable.

This <>c__DisplayClass2c is an autogenerated internal class that holds the different types of anonymous delegate I am using in my application. However, as we can see from the below image, it is not [Serializable]:

alt text

What would be the best way to change my application so this does work? Make my own <>c__DisplayClass2c-type class and make it serializable? Or is there a better way?


EDIT: In the end I just made my own class, instead of the autogenerated one. I helps with debugging as well, actually having a descriptive name rather than just b__12().

+3  A: 

It usually makes very little sense to serialize a delegate. Normally, you would choose to mark delegate fields as [NonSerialized], and recreate it when needed. If your main intent is to store the delegates, then I would recommend thinking of a completely different approach, frankly.

Additionally, note that BinaryFormatter is brittle if you are planning to keep the data for any length of time (but acceptable for transient data)

To look further, I suspect we'd need to look at some reproducible code.


Update: actually, I suspect you could serialize it by writing your own explicit capture classes (rather than the compiler-generated ones). But I still think the concept is fundamentally flawed. And writing capture classes by hand isn't fun.


To address the points in comments; re long term storage - because it is so darned brittle - something as simple as changing from:

public int Value {get;set;}

to

private int value;
public int Value {
    get {return value;}
    set {
        if(value < 0) throw new ArgumentOutOfRangeException();
        this.value = value;
    }
}

will destroy serialization; as will changing assemblies, type names, "looking at it funny", etc.

Re the delegates; to give an example of a manual capture; instead of:

int i = ...
Predicate<Foo> test = delegate (Foo x) { return x.Bar == i;}

you might do:

int i = ...
MyCapture cpt = new MyCapture(i);
Predicate<Foo> test = cpt.MyMethod;

with

[Serializable]
class MyCapture {
    private int i;
    public MyCapture(int i) {this.i = i;}
    public bool MyMethod(Foo x) {return x.Bar == i;}
}

As you can see - not always trivial (this is the simplest of examples).

Marc Gravell
I knew a comment like this was coming - it does seem to be a very strange thing to do. However, delegates seem to be the best (or at least fastest) method for what I am trying to do. Creating the delegates takes a (relatively) long time, so it would be good if I could store them. I've now realised after looking at Expression Tree from Nader Shirazie's comment that I am essentially trying to recreate a limited Expression Tree system/syntax (ie building up code from delegates). And why is BinaryFormatter bad for long term storage of data?
Callum Rogers
Ah, thanks. So another system like protobuf-net or XML wouldn't have this "brittle" problem as they don't store types/versions/assemblies etc?
Callum Rogers
Exactly; most serializers only store the *data*; this makes it implementation independent, and generally shorter. `BinaryFormatter` stores type/field information, which is **very** implementation specific.
Marc Gravell