System.Uri and MarshalByRefObject

As you might have noticed, in V1.0 and V1.1 System.Uri is MarshalByRef… Some of you noticed this and thought it was odd, as did I because MarshalByRef is suppose to be only for types that encapsulate external resources that need to be shared across AppDomains. 


Well, you will be happy to hear we fixed this in Whidbey.  Although technically a breaking change, we don’t believe this will actually break any applications as it would have been hard to take advantage of the MarshalByRef properties of System.Uri.  Lance Olson, who owns System.Uri told me we made this change for a couple of reasons:


1)       Security – Uri is immutable and yet if you could pass it by ref then there is the potential for it to be changed by the caller without the callee knowing.

2)       Performance – MBRObj implied a significant performance (~100%) hit to System.Uri with no functional benefit.



I hope that satisfies your curiosity and helps you make a better choice about what to make MarshalByRef. 

Comments (6)

  1. Doug McClean says:

    Thanks for the info :).

    Glad to hear this has been fixed, and that I wasn’t missing anything obvious.

  2. Brad Abrams addressed my previous questions about why System.Uri is MarshalByRef in v1.0 and v1.1 of Microsoft.NET.

  3. Cool.

    So the next question is: why on earth is System.Windows.Forms.Control MBRO? My understanding is that you’re never meant to use it remotely, and that bad things happen if you do. (All the incoming calls will be on thread pool threads for starters, but for all I know there are other reasons to avoid this too.) So why is it MBRO?

  4. Eric Newton says:

    Good question, Ian.

    To the owner of System.Uri: It would be nice to have a little more flexibility with Uri, to be able to build support for newer Uri schemes. I have floating in my head a SQL uri scheme:


    I had built a SqlUri type, but getting it to work was very difficult because the Uri constructors REQUIRE everything to be proper right on the constructor line, so I had a nasty looking call to the base constructor.

    With respect to the immutability, it would still be nice to be able to maybe virtualize the Parse method, so more custom functionality can be implemented.

  5. Brad Abrams says:

    Per Ian’s comment from above, I talked to the WinForms guys about why Control is MBRO, here is the answer…

    Our preference would be for it to not be mbro, but because it is hosted via com cross domain in IE, we needed to make it mbro in order for the com calls to marshal to the com apartment.