A “Breaking” change with remoting when moving to 1.1

it's not really breaking , it more like changed without notice, it's like change and not document it , it's like change and throw an exception that's not informative too much, it's like change WO telling us (not even ingo rammer).

what am I talking about?

everybody knows by now that if you want to serialize an exception over remoting , you need to implement ISerializble in order to serialize any custom data you have.

there is a diffirence in 1.1 regarding serialized exception across machines. you'de think that testing this problem on you machine is enough... BZZZZZ ,,, wrong. when Remoting is serializing an exception it knows you are crossing the machine boundary, so it's not always safe to tell the client things like: stack trace and such, so unless you specifically specify the next:


        <customErrors mode="Off" />


you will have a lot of fun trying to understand why this is happening.

more over there is no documented/undocumented way to do this in code, me and Lior digged remoting code for over a day to try and find it as you can see here:

Working Out Remoting

we didn't find it, we think there may be a way but ....

I think it's totally wrong to do that, especially if I have production time code or a version I can't redeploy but still want to use v1.1. now I have to add specific code like:


even If I'm not using configuration files in order to config my remoting.

anyway I hope that this helps somebody


Comments (2)

  1. Greg Keogh says:

    Hi Yosi,

    We are also going mad trying to change customErrors to Off in code (we don’t use config files). I spent 4 hours wasting my time experimenting and searching, but you tried for even longer and searched much deeper. If you ever learn more on this, please send me an email on greg@mira.net.


    Greg (Melbourne Australia)

Skip to main content