3

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 http://bayimg.com/image/maebbaacj.jpg

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().

Community
  • 1
  • 1
Callum Rogers
  • 15,630
  • 17
  • 67
  • 90
  • You say the class is autogenerated -- how is it done? Do control it? Is it generated by a 3rd party component? – Nader Shirazie Oct 24 '09 at 17:24
  • It is autogenerated by the compiler - it has the [CompilerGenerated] attribute. I think it is just a class/place to store a number of very similar anonymous delegates (they are all void and accept a string[] as a parameter in this case). – Callum Rogers Oct 24 '09 at 17:27
  • Then yeah, try generating your own class. You may also have a problem with anonymous methods (I haven't tried it, so I don't know), in which case, try non-anonymous versions. If even that doesn't work, you could try turning the methods into expressions first (those _should_ be serializable) – Nader Shirazie Oct 24 '09 at 17:30
  • Compiling Expression trees run into the exact same problem as Actions you still need to make the autogenerated class. – Callum Rogers Oct 24 '09 at 18:41

1 Answers1

4

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
  • 1,026,079
  • 266
  • 2,566
  • 2,900
  • 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 Oct 24 '09 at 18:40
  • 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 Oct 24 '09 at 21:38
  • 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 Oct 25 '09 at 07:26