Using System.Uri in Your Application

In the course of developing your application or classes that work with a URI, there are a few key guidelines that you should follow to ensure that your application gets the best performance and security. The System.Uri type is extremely valuable when it comes to parsing and validating a URI. However, this functionality comes at a cost and there are cases when it should not be used.

When to Use System.Uri

Consider using System.Uri in your application whenever you need to parse or validate a URI in any way. Like many things in development, a URI can appear to be very simple on the surface but turn out to be quite complex when you begin to consider all the cases. We ve seen that developers who avoid the temptation to write a simple URI parser are often rewarded later on in the development cycle when application logic or input assumptions change, causing the simple logic to become much more complex.

A significant cost is associated with constructing an instance of System.Uri when compared to that of simply creating a string. Most of this cost is because of the URI validation logic. Because of this cost, it s important that methods in your application that parse a URI and then pass the URI on to any other method should always pass the URI as a System.Uri type rather than as a string. This way, you avoid a scenario where the URI is parsed multiple times as it gets converted from a string to a Uri instance, back to a string, and back to a Uri instance as it moves through the call stack.

When Not to Use System.Uri

Because of the cost of construction, System.Uri should not be used if you never intend to parse or validate the URI being represented. In these cases, a String type should be used to contain the URI.

In version 1.1 of the .NET Framework, System.Uri implements the MarshalByRefObject interface, which means that passing a System.Uri object as a parameter in a remote call will cause the Uri instance to be passed by reference rather than by value. Passing the Uri instance by reference can lead to unintended circumstances such as having an extremely high performance cost of accessing the properties that you think are local when they are really being remoted to another application that s possibly on another machine. The fact that System.Uri implements MarshalByRefObject can also lead to a security or functional issue in your code if the application is making decisions based on an assumption that the Uri instance is immutable. Because of these reasons, you should avoid passing a URI as part of the signature in a remote procedure call. In cases where you must pass a URI in a remote procedure call, consider passing the URI as a String rather than as an instance of System.Uri .

Note	It is anticipated that in the next major release of the .NET Framework, MarshalByRefObject will be removed from the System.Uri signature so that it is always passed in remote calls by value rather than by reference.