So can I resolve #83 and #85 with "Won't Fix"? On Wed, Mar 4, 2009 at 7:02 PM, Krzysztof Kozmic <[email protected]> wrote:
> >>> [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. > > > -- Jono --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
