>>> [email protected] 2009-03-03 18:05 >>> > The fiirst issue, that surfaced itself in this bug report is IMHO wrong > assumption that DP takes about types implementing ISerializable. > An implicit contract exists that types implementing ISerializable must also > have a specific constructor. DP checks for existence of this constructor, > and in case this constructor is not present, it throws. > The thing is, this constructor is not required for type to be perfectly fine > serializable. Instead a IObjectReference interface can be used to delegate > serialization/deserialization responsibilities to. In fact, this is how > interface proxies are deserialized in DP, though they do not have the > constructor.
As I just wrote on the other thread, as I didn't see this message, DP also uses object references (for all proxies, not only interface proxies), so supporting classes using their own IObjectReference wouldn't be that easy. Right, I see that now. I thought that ProxyObjectReference would wrap inner objectreference and that it would work. It seems that SetType does not work that way, since when proxied class does its SetType, the information set by proxy is lost :/ This makes it really hard to implement, and I currently have no clue how to approach it (considered we would anyway) > The other issue is proxying proxy types specifically. I for example wanted > to stub a stub type with Rhino.Mock in one test. > If we wanted to enable this, we would have to change the way proxy fields > are stored in/retrieved from SerializationInfo object, since currently inner > type will try to add values under the same key as outer type, which will > result in exception. > > The question remains however, if this corner case is worth pursuing. I'm not sure as well - would you really need to serialize proxies of proxies? Or, in your case, serialize a stubbed stub? I dont want to serialize them. I want to be able to create the proxy, even if serialization will be broken. Considered how dificult it would be to implement (unless someone has some briliant idea), I think it would be better to leave this as it is, and not support this scenario. This is an obscure corner case anyway. We could solve this by nesting the SerializationInfos in some way, although I'm not sure whether this is possible. Can you put a SerializationInfo into a SerializationInfo? Probably not. You can't even check whether a key already exists, can you? I don't think so, no. Krzysztof Fabian CONFIDENTIALITY NOTICE This message is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is proprietary, privileged, confidential or otherwise legally exempt from disclosure. If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please delete all copies of this message and notify the sender immediately by return mail or fax ATSI S.A.(+4812) 285 36 04. Any email attachment may contain software viruses which could damage your own computer system. Whilst reasonable precaution has been taken to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should therefore carry out your own virus checks before opening any attachments. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en -~----------~----~----~----~------~----~------~--~---
