Hi Ian, > I wrote the NUnitTask stuff originally. I got it to where it is now, > decided I didn't know enough about app-domains at the time and kinda > backed away from it. I agree we should do the right thing. How many > classes would need the serializable attribute ? Do derived classes > automatically inhereit it ?
Unfortunately for us, not, it's not inherited. Basically, for a type to be actually serializable, the type itself, and all of its base classes need to be serializable. In our case, that means that the NUnitTest class needs to be serializable. Since NUnitTest derives from Element, that means Element (and a few classes in between), needs to be serializable. And here's the rub: The Element class holds a reference to the Project it's defined in, so to get automatic serialization, Project itself would need to be serializable. And Since the Project class holds the Task and Element lists, all of those would need to be serializable, too. I'm not sure that's very acceptable right now. Now, One could possibily consider minimizing the list of serializable types, and implement some kind of custom serialization (via ISerializable) in the Element class, but, quite frankly, I'm not sure what we could do on deserialization to get the Project back.... unless project itself was MBR... It's either that, or perhaps doing a full revamp of the NUnit helper classes so that they don't deal with the build elements/tasks directly but with an alternative class hierarchy that would need to be maintained. So, what do you guys think? -- Tomas Restrepo [EMAIL PROTECTED] ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
