In the .NET 3.5 timeframe and earlier, many client developers referenced System.Web.dll in order to be able to use System.Web.HttpUtility and its helpful encode/decode and parse methods. While those functions were really useful, the full framework is a pretty hefty tax to pay for just a couple methods.

I ran across this tax today when I tried to use a popular twitter library (written in .NET 3.5) with a .NET 4 client profile project. That project references the full System.Web.dll and won't compile under a client profile project in .NET 4.

You no longer need to rely on ASP.NET DLLs on the client just to encode/decode HTML.

The .NET 4 client profile includes a new class that provides some of the functionality of System.Web.HttpUtility, without requiring all the baggage of ASP.NET on the client. Yes, you can finally decode and encode HTML strings/streams without having to use HttpUtility.

Here's the list of methods from MSDN.

MSDN Information on the WebUtility class

By default, when you create a new WPF project, it uses the client profile. When building client applications, you should always attempt to stay within the client profile, unless you know all your users will have the full .NET framework. The client profile itself for .NET 4 is pretty tight, and a quick download. A user will the full .NET framework will be able to run your application just fine. If the user doesn't have the right version of the .NET framework installed, their download and install will be much quicker.

string html = "<p class='foo'>I am the walrus. You & I, me and you.&nbsp;End-of-line</p>";

string encoded = WebUtility.HtmlEncode(html);
string decoded = WebUtility.HtmlDecode(encoded);

Debug.WriteLine("Original: " + html);
Debug.WriteLine("Encoded: " + encoded);
Debug.WriteLine("Decoded: " + decoded);

// Output:
//Original: <p class='foo'>I am the walrus. You & I, me and you.&nbsp;End-of-line</p>
//Encoded: &lt;p class=&#39;foo&#39;&gt;I am the walrus. You &amp; I, me and you.&amp;nbsp;End-of-line&lt;/p&gt;
//Decoded: <p class='foo'>I am the walrus. You & I, me and you.&nbsp;End-of-line</p>

Encoding and Decoding URIs / URLs

Encoding and Decoding URIs can be done through the static methods on the URI class. These functions aren't new to .NET 4, but many folks aren't aware they're there.

string url = "http://foo.com/search.html?code=xyzzy&id=3263827&s=I have spaces don't I";

string encoded = Uri.EscapeUriString(url);
string decoded = Uri.UnescapeDataString(encoded);

Debug.WriteLine("Original: " + url);
Debug.WriteLine("Encoded: " + encoded);
Debug.WriteLine("Decoded: " + decoded);

// Output:
//Original: http://foo.com/search.html?code=xyzzy&id=3263827&s=I have spaces don't I
//Encoded: http://foo.com/search.html?code=xyzzy&id=3263827&s=I%20have%20spaces%20don't%20I
//Decoded: http://foo.com/search.html?code=xyzzy&id=3263827&s=I have spaces don't I

You can use the same type of code to escape name/value pairs for data in a form submission.

Parsing Query Strings

That leaves us to ParseQueryString, the only other commonly-used HttpUtility method that caused folks to pull in the full framework when the client profile would have otherwise worked.

Fortunately, this isn't a hard problem to solve. You can brute force it with some splits, or you can go the regex route like some folks did here.

Those three things together: HTML Encoding/Decoding, URL Encoding/Decoding, and Query String Parsing should be enough to reduce or eliminate your dependence on the full .NET framework.