FiddlerCore and the .NET Client Profile

As the .NET Framework grew in size from version to version, there was an increase in the clamor for a smaller version of the Framework. The idea was that this smaller version would be quicker to download and install, with the tradeoff that it would support only client applications, leaving out the assemblies used by ASP.NET and other server applications. Starting in Version 3.5, the .NET Team answered that request by creating the .NET Framework Client Profile, a subset of the Framework which omits the classes that client applications are unlikely to use.

Until recently, FiddlerCore had a dependency on the System.Web.dll assembly. FiddlerCore relied upon the HttpUtility.HtmlEncode method when encoding error messages for display in the browser; the call was used to mitigate script-injection attacks. Unfortunately, that reliance meant that applications built on top of FiddlerCore would not run on the .NET Client Profile.

This limitation is fixed in FiddlerCore 2.2.9 and later; FiddlerCore now contains its own implementation of the HtmlEncode function, and no longer relies upon the System.Web.dll assembly. This means that FiddlerCore.dll will no longer itself introduce a dependency on classes not in the Client Profile. Note: The full version of Fiddler itself still uses a number of other APIs in System.Web and hence it does require a full-install of the Framework to run.

At some point in the near future, FiddlerCore will be made available in a CLR 4.0 version for developers who are building applications who are building applications which target the latest version of the CLR.


Comments (2)

  1. We faced a similar problem adopting the .NET Client Profile. There’s a handful of web-related classes that are useful for any application. We were able to find good replacements for HTML Encode and Decode by using Microsoft’s Anti-XSS library instead.

  2. Topher Hansen says:

    So, what is the recommended way of using urlencoding/decoding in the FiddlerScript?