Retrieving huge amount of data from WCF service in Silverlight application

Today, I was trying to figure out why my WCF service call was always throwing the generic NotFound exception when trying to retrieve large datasets. I had all the buffer limits set to 2147483647 (int.MaxValue) at Silverlight service configuration file as well as WCF service configuration section under web.config. Some more analysis revealed that I was getting a System.Net.WebException, saying: The underlying connection was closed: The connection was closed unexpectedly. After some research, I found that I need to set the maxItemsInObjectGraph for dataContractSerializer to some higher value in my web.config.

So, if you are trapped in a similar situation, here are two steps to ensure that you can retrieve large amount of data from WCF service:

1. Enable Silverlight client to retrieve huge chunks of data by enabling large buffers. You need to increase buffer and message size limits for the binding inside ServiceReferences.ClientConfig with something like:

            <binding name="BasicHttpBinding_SilverlightWCFService"
                <security mode="None" />
        <endpoint address="http://localhost:1252/SilverlightWCFService.svc"
            binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_SilverlightWCFService"
            contract="SilverlightWCFService.SilverlightWCFService" name="BasicHttpBinding_SilverlightWCFService" />

2. Enable WCF service to send large amount of data. You need to set the binding buffer limits as well as tje DataContractSerializer’s maxItemsInObjectGraph value. Here’s an extract from web.config with all the limits set to maximum:

            <!-- Create a custom binding for our service to enable sending large amount of data -->
            <binding name="MyBasicHttpBinding"
                    maxStringContentLength="2147483647" />

            <!-- Enable the serializer to serialize greater number of records -->
            <behavior name="SilverlightWCFLargeDataApplication.Web.SilverlightWCFServiceBehavior">
                <serviceMetadata httpGetEnabled="true"/>
                <serviceDebug includeExceptionDetailInFaults="false"/>
                <dataContractSerializer maxItemsInObjectGraph="2147483647"/>

    <serviceHostingEnvironment aspNetCompatibilityEnabled="false"/>
        <!-- Bind the WCF service to our custom binding -->
        <service behaviorConfiguration="SilverlightWCFLargeDataApplication.Web.SilverlightWCFServiceBehavior"
            <endpoint address="" binding="basicHttpBinding"
            <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>

That was all related to sending greater amount of data from WCF service to Silverlight application. However, if you want to send large amount of data from Silverlight to WCF service, you need one more step as you can reach the maximum permitted http request length limit (this is 4MB by default). This again can be solved by tweaking the web.config. E.g. to allow 10MB data, you need something like:

  <httpRuntime maxRequestLength="10240" />

That’s all. Let’s enjoy developing LOB applications with this great platform.

How to create and use Extension Methods in C#

As I promised in my previous post, here’s a simple example to create and use extension methods. Extension methods are a powerful feature introduced in Dot Net 3.0/3.5 that allow us to inject/add a custom method in any existing type (even if the type is Sealed/NotInheritable). Lets say, we want to add a new method IsPrime to the existing int (System.Int32) type, then we need to write an static method in an static class like this:

 public static class MyExtensions
        public static bool IsPrime(this int integer)
            //implementation here
            return true;

Now, this IsPrime method will be associated with every int type in our project, as depicted in the following screenshot:

Extension Method Demo

Thats all. I just wanted to demonstrate extension methods using a very basic example; if you need more information, try msdn or google.


In WPF/Silverlight, binding UI objects such as DataGrid or ListBox to collections is typically done using an ObservableCollection instead of the generic List object. This way, our UI is automatically synchronized since the observable collection provides event notification to WPF data binding engine whenever items are added, removed, or when the whole list is refreshed. The LINQ extension methods that return a collection actually return IEnumerable<T>. The .NET framework for Silverlight provides built-in extension methods to convert IEnumerable<T> to List<T> and Array<T> but there’s no method available to convert the collection to ObservableCollection<T>(WPF developers can simply use this constructor overload) . So here’s one you may find useful:

public static class CollectionExtensions
    public static ObservableCollection<T> ToObservableCollection<T>(this IEnumerable<T> enumerableList)
        if (enumerableList != null)
            //create an emtpy observable collection object
            var observableCollection = new ObservableCollection<T>();

            //loop through all the records and add to observable collection object
            foreach (var item in enumerableList)

            //return the populated observable collection
            return observableCollection;
        return null;

Extension methods are very powerful and I am planning to post an example demonstrating their potential.

C# Coding Standards

I recently came across this post from Clint Edmonson. It presents a reference document for coding standards (for C# as well as VB) you may find useful.

Securing Silverlight Application and WCF Service using ASP.NET Authentication Techniques

Security is an issue that experts are discussing since the birth of Silverlight. A typical enterprise Silverlight application will consist of one or more Silverlight pages communicating with one or more WCF services. There are three major security concerns here:

  1. Silverlight 2 supports communication with a WCF service in simple text (the basicHttpBinding), so anyone can use a packet sniffer (e.g. Fiddler) to read our data.
  2. Anyone can access our WCF service, call its methods and get our data.
  3. Anyone can download our Silverlight application (the .xap file), open it (since it is simple a zip file), extract the DLLs and use Reflector to read all our code.

The first problem can be solved by securing the transmission via transport security (using https protocol). More on this can be found at MSDN here. In this post, I will try to address the last two issues.

The good thing is that the Silverlight application and WCF service is hosted inside an ASP.NET website and luckily ASP.NET provides good tools around authentication so we can apply ASP.NET authentication techniques to secure those. The approach I like is to secure the entire ASP.NET web application using either Windows or Forms authentication and deny all anonymous users. This can be done by configuring the web.config as:

  <authentication mode="Windows"/> <!-- or Forms -->
    <deny users="?"/>

This way, if anyone tries to access the WCF service, or download the Silverlight .xap file, or view a page inside the ASP.NET website, the ASP.NET engine authenticates the request and only authorized users are able to view the application or use the service.

So now, if our application is configured to use Windows authentication, the ASP.NET engine authenticates the request via integrated windows authentication. If it succeeds, users are automatically redirected to the Silverlight application; otherwise they get a HTTP 401.1 – Unauthorized message.

And, if our application is configured to use Forms authentication, the ASP.NET engine takes the user to an aspx login page. Once the user is validated (we can use either ASP.NET built-in authentication or any custom implementation to authenticate the user), he/she is redirected to the Silverlight application.

To observe this, you can download this application (Be sure to first rename the file to zip; this is a WordPress requirement) and toggle its authentication technique between Windows and Forms using web.config.

Note that the application also demonstrates how to get the logged in user in Silverlight using a WCF service call. The key is that we can use System.Web.HttpContext.Current.User to get the current user principal if the WCF service is running in ASP.NET compatibility mode.

Screenshot of demo application

At this point, we have made sure that our application and WCF service is only accessible to authorized users. But the problem still exists to a small extent, although narrowed down to authorized users instead of general public. To further secure our application, we need to use some .NET obfuscater. This will ensure that no one, including authorized users, will be able to decompile our code using .NET reflector. And, to further enhance our WCF service security, we need to implement declarative or imperative security checks for our service methods. As with typical ASP.NET applications, we may need a custom implementation of IPrincipal and IIdentity for securing the WCF service using declarive security attributes.

That’s all. Let me know what you do think in the comments section below.

Using Custom Principal with Forms Authentication in ASP.NET

FormsAuthentication is the most generic authentication for securing ASP.NET applications. By default, it assigns a GenericPrincipal to HttpContext.Current.User (as well as Thread.CurrentPrincipal) with a FormsIdentity object.
If we need to use a custom implementation of IIdentity and IPrincipal with forms authentication, we simply need to hook the AuthenticateRequest event in global.asax.cs and assign our CustomPrincipal to HttpContext.Current.User.

Here’s how I like to do it:
In my login page, after validating the user credentials, I simply store the username in my FormsAuthentication ticket like this:

protected void Login1_Authenticate(object sender, AuthenticateEventArgs e)
	//validate from some data store here
	SecurityManager securityMgr = new SecurityManager();
	if ( SecurityManager.Authenticate( Login1.UserName, Login1.Password )
		//User authenticated, now store UserName in Forms Authentication ticket
		FormsAuthentication.RedirectFromLoginPage(Login1.UserName, Login1.RememberMeSet);

My implementation of CustomIdentity requires a username to populate itself. This way, I am able to use the following code in my global.asax.cs:

protected void Application_AuthenticateRequest(object sender, EventArgs e)
	if (Request.IsAuthenticated)
		//get the username which we previously set in
		//forms authentication ticket in our login1_authenticate event
		string loggedUser = HttpContext.Current.User.Identity.Name; 

		//build a custom identity and custom principal object based on this username
		CustomIdentitiy identity = new CustomIdentitiy(loggedUser);
		CustomPrincipal principal = new CustomPrincipal(identity);

		//set the principal to the current context
		HttpContext.Current.User = principal;

We’re done. Now we will get HttpContext.Current.User as well as Thread.CurrentPrincipal set to our CustomPrincipal object anywhere in our ASP.NET application; screenshot below(click to enlarge):

Setting current context to CustomPrincipal

The advantage we get is that now we can use declarative security checks to protect our methods, like this:

PrincipalPermission(SecurityAction.Demand, Role="MyCustomRole")]
public string MySecureMethod(int parameter)
	// If anyone not in "MyCustomRole" tries to call this method,
	// a SecurityException is thrown
	return string.Empty;