New .NET Technology to watch: .NET Native

Hello World,

.NET Native is a pre-compilation technology for building Universal Windows apps in Visual Studio 2015. One can compile managed IL binaries into native binaries using the tools provided. Every managed (C# or VB) Universal Windows app will utilize this new technology. The applications are automatically compiled to native code before they reach consumer devices.

More Information:  MSDN

.NET Native .NET Native Blog

More information as I get my head around this technology.

Happy Coding!

Posted in Uncategorized

IDisposable Pattern: A refresher on the need and correct implementation

Hello World,

One may wonder why another post on IDisposable? After all, how difficult could an implementation of an interface that has only one void parameter-less method be? Well, this post is a result of my interactions with developers during interviews and surprisingly, there seems to be considerable confusion with regards to garbage collection and IDisposable’s purpose of existence. I would try to cite some authoritative resources and attempt to clear the matter in a comprehensible manner.

Garbage Collection and Managed Memory (Crash Course!)

The topic of Garbage Collection and managed memory is intensive and I would not try to repeat what is already well covered in depth on MSDN and in reference books such as Jeffery Richter’s CLR Via C#, but for the sake of completeness, let me highlight the important facts about GC in .NET

  • Garbage Collector (hereafter referred to as GC) in the CLR is designed to free the programmer from the concerns of allocation and de-allocation of memory and as such unless you declare unsafe blocks in your code, it is impossible to cause a memory corruption in the .NET world (i.e. use a reference to a memory block that has been freed)
  • The CLR’s GC works in phases:
    • Executing Threads are paused
    • GC starts with a “Mark” phase wherein it walks the thread stack and marks all objects that are referred (remember that in a collection type containing reference type elements, the elements that are referred to will be marked)
    • This is followed by a “Sweep” or compacting phase wherein the marked objects are compacted on top of unmarked objects in the heap to have contiguous allocation – thus avoiding fragmentation in the heap.
    • Next, the allocation pointer is updated to point to the next available memory address where new objects may be allocated. The references to the objects that were moved due to compaction are updated to their new location in the heap.
    • Paused Threads are resumed
  • The GC is generational – it keeps objects in generations based on their age to optimize collection
    • GEN 0: is where newly created objects are allocated (unless they are large enough to be allocated on the LOH or large object heap). This is also the generation that is collected most often as the GC assumes that the newer an object, the shorter its lifetime
    • GEN 1: is sort of a staging area for objects that were referred (marked) during the collection of GEN 0. These objects have effectively survived one collection and would be looked at again if collection of GEN 0 does not free up enough memory for the next allocation
    • GEN 2: consists of objects that have survived 2 collection cycles (or not looked at yet due to their large size and hence allocation on the LOH) and would only be looked at during a full collection – when all generations are checked and collected
  • The occurrence of a garbage collection is not deterministic – it happens when there is memory pressure – i.e. when a new object needs to be allocated and there isn’t enough contiguous memory block to allocate it.

Enter IDisposable

That the entire world is not managed would be an understatement! There will be situations when managed code needs to interact with the unmanaged world – database connections, COM objects, sockets, OS native Handles – file handles, wait handles and the like. In such scenarios, it makes a lot of sense to have a deterministic way of cleaning up the unmanaged resources – this is where IDisposable steps in. In a nutshell then:

  1. A type must implement IDisposable whenever it wraps unmanaged resources. Common scenarios are database connections, Wait handles, Mutexes, semaphores etc.
  2. IDisposable should also be implemented if your type is interacting with other IDisposable types in the code unless your class manages the lifetime of the IDisposable resource completely in itself. E.g. if your class creates a file handle via the FileStream class and returns the reference from a public method, then your class should also implement IDisposable and call the FileStream’s Dispose method from your Dispose method.

Unless your class falls in one of the two categories above DO NOT IMPLEMENT IDisposable. The GC is smart enough to do the best thing required for your program!

Basic Implementation of IDisposable

Let’s say we have a class that wraps a native resource that must be cleaned up, then the following is how a typical implementation would look like:

/// <summary>
/// Typical implementation of IDisposable
/// </summary>
public class DisposableType : IDisposable
{
        /// track the disposed state to avoid unnecessary work
        private bool _disposed;

	/// <summary>
	/// A protected method to allow derived types to override and allow customization
        /// can be made private in addition to marking the class sealed
	/// </summary>
	protected virtual void Dispose(bool disposing)
	{
             // if already disposed, we're done here
             if (_disposed) return;

    	     if (disposing)
	     {
		// Release managed resources as well
	     }

	     // Release unmanaged resources always

             // Mark that we are disposed now
             _disposed = true;
	}

	/// <summary>
	/// IDisposable.Dispose method
	/// </summary>
	public void Dispose()
	{
	     Dispose(true);
	     // Suppress the Finalization on this object
	     GC.SuppressFinalize(this);
	}
}

Let’s touch upon the intent of the code snippet above:

  • The IDisposable.Dispose() method has just two lines and this is almost always how the code inside Dispose should be
    • The Dispose(true) call calls the protected method and indicates that both managed and unmanaged resources must be cleaned up
    • GC.SuppressFinalize call tells the Finalizer that we are taking care of the cleanup and it should not bother running on our object

Variation: A class derived from an IDisposable class

There are situations when you have a derived class that inherits from another IDisposable type and also has cleanup of its own to do. This is how the code would like then:

public class Derived : DisposableType, IDisposable
{
 	private bool _disposed;

	///
	/// Cleanup resources held by Derived as well as call base class' dispose
	///
	protected override void Dispose(bool disposing)
	{
		if (_disposed) return;

		if (disposing)
		{
			// Release managed resources as well
		}

		// Release unmanaged resources always

		_disposed = true;
		// Call base
		base.Dispose(true);
	}

	/// <summary>
	/// IDisposable.Dispose method
	/// </summary>
	public void Dispose()
	{
		Dispose(true);
		GC.SuppressFinalize(this);
	}
}

 Variation: A class that has a Finalizer

.NET has the concept of object finalization to allow scope for the object to do some specific cleanup just before it’s memory is reclaimed. It may sound benevolent on part of the designers of the .NET system, but Finalization is complex and should be avoided unless absolutely critical. The System.Object class has a protected Finalize method that is available to all .NET types as all of them inherit from object. If a type requires Finalization, it should create a Destructor – declared by using a construct that looks like a parameterless constructor without any access modifiers and with a tilde in front. So if I have a class called Finalizable, its Finalizer would look like so:

public class Finalizable
{
   // only relevant code shown

   ///
   /// Finalizer
   ///
   ~Finalizable()
   {

   }
}

Some quick observations on Finalization:

  • As is obvious from the snippet above, in C#, the finalizer of a class cannot be called from outside it
  • When the GC looks at an object with a Finalizer, it places the object on a separate queue that is processed by a separate Finalizer thread. Only when the Finalizer thread has had a chance to look at the object in this queue and it remains unmarked (i.e. there are no references to this object) can the GC reclaim its memory.
  • The above fact means that objects with Finalizers would survive longer and thus may hold on to memory longer than they intend to! For details regarding all the costs involved in Finalization, see reference number 3. in references at the end of this post

To quote from Stephen Cleary on when a class should implement a Finalizer:

For a class owning a single unmanaged resource, implement IDisposable and a finalizer

This is how the type with a Finalizer should implement IDisposable:

public sealed class NativeResourceWrapper : IDisposable
{
    private bool _disposed;

    public IntPtr Handle { get; set; }
    public bool IsInvalid
    {
        get { return (this.Handle == IntPtr.Zero); }
    }

    private void CloseHandle()
    {
        if (this.IsInvalid) return;
        // Close handles, perform cleanup here

        this.Handle = IntPtr.Zero;
        _disposed = true;
    }

    public void Dispose()
    {
        this.CloseHandle();
        GC.SuppressFinalize(this);
    }

    ~NativeResourceWrapper()
    {
        this.CloseHandle();
    }
}

NOTE 1: The correct way to wrap a native resource is to derive your type from the abstract SafeHandle class.

Summary

When designing types, pay careful attention to when you really need to implement IDisposable. When you do, adhere to the recommendations presented and you’ll be fine 🙂

References

  1. Stephen Cleary on IDisposable and Finalizers [Recommended: Read all related posts!]
  2. Scott Dorman on CodeProject
  3. Must Read: Thorough coverage on Finalization and its costs [Note:this is dated, but even then, gives great insight]
  4. Stephen Cleary on “Should I set variables to null to assist GC

Until next time,

Happy Coding!

Tagged with: , ,
Posted in .NET, Best-Practices, C#

Programmer Interviews and the law of “Leaky Abstractions”

Hello World,

I’m been involved in a lot of interviews lately and sometimes get asked by hiring managers why it is so hard for us to get good people. I try explaining (not very well I guess!) that to succeed as a software developer, one must have a certain level of in-depth knowledge and barring that, it will always be a struggle for both the new hire and the incumbent programmers on the team. This does not mean that I was perfect always, far from it, but you must feel that the interviewee has put in some rigour and feels that in-depth knowledge is necessary rather than just knowing how to drag a control and handle it’s click event!

I read about the law of leaky abstractions and it sounded like the perfect alibi for what I’ve been trying to communicate – so in this post, I’ll try and use Joel Spolsky’s expertise to prove my point.

The Law

For the uninitiated, Joel Spolsky is the CEO of Stackexchange, the company behind stackoverflow.com (I don’t think I’ve to introduce stackoverflow to any programmer who’s written more than her hello world programs!). He’s also a much admired and widely respected thought leader in the programmer community. He’s the one who coined the term “Leaky Abstraction” which reads like so:

All non-trivial abstractions, to some degree, are leaky

My own inference from reading Joel’s musings on the subject is that to be an efficient programmer, one must know and understand the underpinnings of how things work under-the-hood. Beyond trivial proof of concept projects, unless one knows how the “magic” happens, there are bound to be times when your world would come to a grinding halt for you won’t know why something that worked yesterday does not work today.

So how are the law and interviews related?

Good question, here’s how: When I’m interviewing someone, I try not to test whether they’ve memorized all the myriad ways of doing something in a particular technology. Instead, my focus is on testing whether they understand how things work under-the-hood, at least in sufficient detail so when stuff doesn’t work, they know where to start looking. If that sounds too abstract, let me cite an example – when discussing a Dependency Injection container, like Unity, in a Web API project, I ask people how Web API knows which container it should use to resolve dependencies and at what stage are the dependencies wired up to the controllers requiring them. Tomorrow, when we are colleagues, I’d expect them to read the details of a TypeInitializationException and understand that a dependency is not yet mapped in the container rather than run around like headless chickens! Similarly, when talking about content-negotiation and Web API, I usually ask them how the server knows what MIME type has been requested and how a MediaTypeFormatter is selected.

There’s More

Turns out, the Joel Test devised by Mr. Spolsky matches exactly what I felt about how programmers must be hired. Joel says in point 11 that whether candidates write code or not during the interview process is an important test of whether the hiring process is doing things right. To add my 2 cents, I’d try and take candidates through a debugging session where they try and fix a bug or at least try and make sense of the intent of the code in front of them. In most places where I’ve worked, I’ve looked at more code written by others before I could get to write my own, so I feel it is important that the candidate can demonstrate that they can do this sort of thing without fretting too much. (not trying to be preachy here Smile)

I also get disappointed (to put it mildly) when I feel that the candidate has not done his homework on his own resume – but that’s another post maybe!

Until next time then,

Happy Coding!

Tagged with: ,
Posted in Interviews, Programming

Double Check Locking in C# – End of life?

Hello World,

After having a discussion with a colleague, I was researching for the correct way to implement double-check locking in C# and .NET 4.5. Turns out a lot of water has flown under the bridge and things have changed quite a bit. I’ll try to document my findings here.

The Scenario

In my codebase, I have a critical section that needs to thread synchronization and I want to avoid unnecessary locking. One of the most common examples that come to mind is that of a Singleton – a class that would have only one instance in the app domain at any time. While creating the singleton instance, one needs synchronization so that one and only one instance is created. Codebases I worked with commonly used double-check locking pattern for the code that created the instance. Consider the following sample:

// <strong>NOTE: THIS SAMPLE MUST NOT BE USED, SEE THE DISCUSSION THAT FOLLOWS</strong>
public sealed class Singleton
{
    private static Singleton instance = null;
    private static readonly object padlock = new object();

    Singleton()
    {
    }

    public static Singleton Instance
    {
        get
        {
            if (instance == null)
            {
                lock (padlock)
                {
                    if (instance == null)
                    {
                        instance = new Singleton();
                    }
                }
            }
            return instance;
        }
    }
}

There’s an excellent and authoritative explanation by Jon Skeet HERE, I wouldn’t repeat all of it, but I would try and add my 2 cents here.

Why Not Use Double-Check Locking?

First: The primary motivation for using double check lock used to be to ensure that we lock only if the instance hadn’t already been created. This depends on the read operation i.e. the if statement that reads the “instance” and compares it to null and the write operation to be exactly in the same order.

Now, on to Why this is unreliable and easy to get wrong:

  1. It is eventually the compiler memory model that’s responsible for honoring the intent of the code above and not every .NET compiler and runtime may work in the same way. E.g. The ECMA CLI specification does not guarantee this
  2. For better safety, the instance variable must be made volatile
  3. The trade-off between thread safety and performance isn’t great here even with a correct implementation using volatile and there are better ways to do this in C# today.

Should I use this pattern or not?

Quick answer: It’s not worth the effort. As Jon Skeet comments here, it is better to use a lock always unless one is absolutely sure that there is a performance bottleneck due to locking. As he says,

“When it comes to threading, a simple and obviously correct pattern is worth a lot”

In a nutshell, if the requirement of double-check locking arises in case of implementing a Singleton, the best way is to use the System.Lazy<T> like so:

public sealed class Singleton
{
    /// Use a lambda that would be evaluated on the first call to the Instance getter 
    private static readonly Lazy<Singleton> lazy = new Lazy<Singleton>(() => new Singleton());
    /// The lazily-loaded instance
    public static Singleton Instance { get { return lazy.Value; } }

    /// Prevent instance creation outside of the class
    private Singleton()
    {
    }
}

So, until next time,

Happy Coding!

Tagged with: , ,
Posted in .NET, C#, Multi-Threading

NUnit Assertions: IsAssignableFrom and IsInstanceOf

Hello World,

A good test coverage and a great unit test framework are like a good insurance cover – they give you the peace of mind and assurance that your codebase is in good shape and guard against inadvertent regressions from seemingly innocent “one line” changes. NUnit is one of the best frameworks for the .NET world and its vast and fluent API lets you get upto speed in no time. Like most well know unit testing frameworks, the heart of an NUnit test is the Assert class. Typically you write your tests like so:

  1. Arrange: Prepare the SUT or System Under Test (instantiate and initialize the code to be tested)
  2. Act: Exercise the code – make a method call, mutate the state etc.
  3. Assert: Check if the resultant state is what the specification expects it to be

This post is regarding two seemingly confusing methods available on the NUnit Assert class: IsAssignableFrom and IsInstanceOf.

Note that this post is using NUnit via the NuGet package and is based on version 2.6.4. You can get it by typing the following command;

Install-Package NUnit -Version "2.6.4"

The Scenario

Let’s consider the following code:

/// An Employee Class
public class Employee
{
    public int EmployeeId { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public DateTime DateOfJoining { get; set; }
}

/// Manager that derives from Employee
public class Manager : Employee
{
    public IList<Employee> EmployeesReporting { get; set; }
}

Now lets consider a scenario where I want to excercise a piece of code that is expected to return an object of type employee which of the two do I use: IsAssignableFrom or IsInstanceOf? Let’s examine

The Tests

So here’s a test method (I’m using both MSTest and NUnit in conjunction here)

[TestClass]
public class EmployeeTests
{
   [TestMethod]
   public void Test_IsAssignableFrom()
   {
        /// Arrange - creating and initializing the repository omitted for brevity
        
        /// Act - Call a method on the repository 
	var employee = _sqlRepository.GetEmployeeById(2341);

        /// Assert - Check if the object received is a type that can be assigned to a Manager 
	Assert.IsAssignableFrom<Manager>(employee); // Passes because Manager is derived from Employee
   }
}

In essence, the Assert.IsAssignableFrom is working exactly like System.Type.IsAssignableFrom (see MSDN) where it is clearly stated that the following is the criteria for “truthfulness” of the method call IsAssignableFrom(type c):

  • c and the current instance represent the same type.
  • c is derived either directly or indirectly from the current instance.
  • The current instance is an interface that c implements.
  • c is a generic type parameter, and the current instance represents one of the constraints of c.

Now where do we use IsInstanceOf then? As the name suggests, when checking if the received object is an instance of the type passed in the generic parameter. Consider this test:

[TestClass]
public class EmployeeTests
{
   [TestMethod]
   public void Test_IsInstanceOf()
   {
        /// Arrange - creating and initializing the repository omitted for brevity
        
        /// Act - Call a method on the repository 
	var manager = _sqlRepository.GetEmployeeById(2341);

        /// Assert - Check if the object received is an instance of type Employee 
	Assert.IsInstanceOf<Employee>(manager); // Passes 
   }
}

Again, this works similar to the Type.IsInstanceOf method.

 Summary

  • Use IsAssignableFrom<T> when checking whether the actual result is the base-type of T
  • Use IsInstanceOf<T> when checking if the result is derived from T (directly or through an inheritance hierarchy)

Happy Coding!

Tagged with: ,
Posted in .NET, Unit-Testing

Logging Frameworks for .NET

Hello World,

Any application out in the real world needs good instrumentation so that when things go wrong (as they will from time to time), one has somewhere to start. Logging has long been a standard and time-tested way for recording context when your application runs into exceptions or suffers a crash. A good logging framework goes a long way in creating a well intstrumented application that is easy to maintain. As the adage goes in developer-land, you may very well be the developer who maintains that app, so better prepare well for a rainy day – coz’ when it rains, it pours!

As .NET is a mature framework, unsurprisingly there a gazillion enterprise grade logging frameworks available – both open source as well as commercial. When looking for a framework, my personal preference is that it should, at a bare minimum, have the following features:

  1. Be actively developed and supported (whether by a thriving and active community or an enterprise) – so that security issues and / or bugs get fixed promptly
  2. Provide a consistent API
  3. Be thread-safe
  4. Provide at least logging to file, eventlog and database out-of-the-box
  5. Be extensible/have a plugin or extensibility point so that custom behavior may be added

And, The Nominees are

NLog and Log4Net are two of the most popular frameworks while MS Enterprise Library also provides a Logging Application Block that is pretty solid. While googling around, I found a commercial solution called SmartInspect that claims to be the super man of logging frameworks as it comes with some pretty awesome features – at a price though! (actually it has a per developer licence and at $199 looks quite pricey IMHO)

Taking a logging framework home

Based on prior experience, I’ve found that it is a wise practice to abstract the core logging API into a custom interface so that your solution isn’t tightly coupled with a logging implementation. You may then build on by creating a Factory that creates an instance of a LoggingAdapter that eventually calls into a concrete logger to log to a configured target (e.g. file).

Turns out there is already an open source library called Common.Logging that provides a simple logging abstraction to switch between different logging implementations. There is current support for log4net, NLog and Enterprise Library logging. The project is on GitHub and is actively developed.

Log File Viewers

It is no good writing logs if you don’t have a good viewer you can use to analyse those log files. Again, at a bare minimum, the viewer must be able to tail a log file (show active logs being written), and provide search and filtering. There are a lot of tools that make the cut:

  1. BareTail from Bare Metal – Has a free as well as paid variant, provides color coding and search
  2. LogExpert – found here – Free and open source, has custom columnizer so can process almost any format
  3. One could use a PowerShell cmdlet to tail log files as described here – free but no colors here!

PS: The company that owns SmartInspect, Gu Rock, has a page that compares features of the most popular logging frameworks here – please note that I have not verified the accuracy of the comparison, there may be changes

They also have a (claimed) comprehensive directory of logging tools here.

Happy Coding!

Tagged with: ,
Posted in .NET, C#

ASP.NET Web API: Content Negotiation, Content-Type, Accept and Accept-Charset in a nutshell

Hello World,

ASP.NET Web API is now the standard, recommended way of building REST based HTTP services. As of writing this post, the latest stable version is Web API 2.2 (semantic version 5.2.2) available from NuGet here.

One of the gazillion cool features that this awesome framework has is Content negotiation and for some strange reason, when I speak to newbies, it appears to either sound like magic or a complete black box! The fact is, if one cares to know, Content negotiation is straightforward and it isn’t too hard to understand how it works. I will try to summarize and present my view on how the whole thing works and the moving parts that matter.

First things first: The basics

If you are a client calling a Web API, the way you would tell the API your preferred format is through the Accept HTTP header. IETF defines the header likes so:

Accept = #( media-range [ accept-params ] )

E.g. Accept: audio/*; q=0.2, audio/basic

Should be interpreted by the server as: “The client prefers MIME type audio/basic but would be fine with any audio type after an 80% mark-down in quality”

When the server responds, it will indicate the response MIME type in the Content-Type HTTP header defined like so:

Content-Type := type "/" subtype *[";" parameter]

E.g. Content-Type: audio/mp3

Should mean that the server is sending back audio that is in MP3 format.

What is Content-Negotiation and how does it work?

By definition, content negotiation (abbreviated as conneg in a few sources) is the mechanism that allows the same URL to serve content in different formats. It follows from one of the tenets of REST which suggests that meta data (such as HTTP headers) be used to represent different formats of the same resources – the URL representing the resource here.

I see this as a nice separation of concern from an architectural standpoint in general where the resource itself does not carry the burden of how it is serialized over the wire – it is rather another component (a MediaTypeFormatter in case of Web API) that handles that concern.

When an HTTP Client (e.g. a browser or any .NET application calling into the Web API) sends an “Accept” header, content negotiation kicks in. The value of this header can be read from several places in a request. Web API by default provides the following 4 media type mappings or places you can configure for the accept media types to be read:

  1. QueryStringMapping: Read the media type header values from query string
  2. UriPathExtensionMapping: Read the media type header values from Uri path extensions
  3. RequestHeaderMapping: Read the mapping from an arbitrary HTTP request header field to a media type header value
  4. MediaRangeMapping: Read the MediaTypeHeaderValues for a request or response from a media range.

As an example, suppose I have a custom media type formatter that is used to return a CSV as the response stream and I want that the client indicate her preference of the format through a querystring parameter, the following line would have to be written in the bootstrap stage (i.e. the Global.asax.cs or WebApiConfig.Register method):

var config = GlobalConfiguration.Configuration;

//// Add the CSV MediaTypeFromatter to the available formatters .
config.Formatters.Add(new CsvMediaTypeFormatter(new QueryStringMapping("format", "csv", "text/csv")));

From the client, the request would now contain a querystring like so (assuming the API exposes this functionality through the URI /data/getdetails)

/data/getdetails?format=csv

NOTE: MediaTypeFormatter can also be defined at a controller level by creating a custom attribute that implements IControllerConfiguration. The controller can then be decorated with this attribute to invoke the custom MediaTypeFormatter:

// STEP 1: Create Custom Attribute
public class UseCsvFormatterAttribute : Attribute, IControllerConfiguration
 {
       public void Initialize(
                               HttpControllerSettings settings,
                               HttpControllerDescriptor descriptor)
       {
          // Clear the formatters list.
          settings.Formatters.Clear();

          // Add a custom media-type formatter.
          settings.Formatters.Add(new MyFormatter());
       }
 }

// STEP 2: Use the attribute on the ApiController
[UseCsvFromatter]
public class DataController : ApiController
{
    // action methods code goes here
}

(Code inspired from Web API official site)

Accept-Charset and Accept-Encoding

The Accept-Charset header is intended to indicate to the server the character set that the client needs. A set of encodings is supported by each MediaTypeFormatter in the Web API pipeline. The default charset for the built-in formatters is UTF-8. What this means is that by default, Web API will use the default encoding for the MediaTypeFormatter that has been chosen based on content negotiation.

The default encoding can be seen and changed on a per-formatter basis like so:

// Code from Global.asax.cs
public class WebApiApplication : System.Web.HttpApplication
{
   protected void Application_Start()
   {
     // NOTE: SupportedEncodings is a mutable collection of character encodings
     // supported by this System.Net.Http.Formatting.MediaTypeFormatter
     // The following code makes UTF-16 as the default encoding for JsonFormatter
     System.Text.Encoding defaultJsonEncoding =
        GlobalConfiguration.Configuration.Formatters.JsonFormatter.SupportedEncodings[0];
     // Add the default at the last index of the SupportedEncodings collection
     GlobalConfiguration.Configuration.Formatters.JsonFormatter.SupportedEncodings.Add(defaultJsonEncoding);
     // Remove UTF-8 from the first index to make UTF-16 the default
     GlobalConfiguration.Configuration.Formatters.JsonFormatter.SupportedEncodings.RemoveAt(0);

     // Some code omitted for brevity
   }

As of this post, Web API does not have an out-of-the-box support for responding to Accept-Encoding header but it is easy to create a handler yourself that takes this header into account by implementing a class derived from System.Net.Http.DelegatingHandler.

Let us walk through creating a handler that would support compression using GZip – this is done in 3 steps:

STEP 1: Create an HttpContentType that represents compressed content

 /// <summary>
 /// Represents GZip compressed content
 /// </summary>
 public class CompressedContent : HttpContent
 {
 private HttpContent originalContent;
 private string encodingType;

 /// <summary>
 /// Initializes a new instance of the <see cref="CompressedContent"/> class.
 /// </summary>
 /// <param name="content">The content.</param>
 /// <param name="encodingType">Type of the encoding.</param>
 /// <exception cref="System.ArgumentNullException">
 /// content
 /// or
 /// encodingType
 /// </exception>
 /// <exception cref="System.InvalidOperationException"></exception>
 public CompressedContent(HttpContent content, string encodingType)
 {
     if (content == null)
     {
          throw new ArgumentNullException("content");
     }

     if (encodingType == null)
     {
         throw new ArgumentNullException("encodingType");
     }

     originalContent = content;
     this.encodingType = encodingType.ToLowerInvariant();

     if (this.encodingType != "gzip" && this.encodingType != "deflate")
     {
        throw new InvalidOperationException(string.Format("Encoding '{0}' is not supported. Only supports gzip or deflate encoding.", this.encodingType));
     }

     // copy the headers from the original content
     foreach (KeyValuePair<string, IEnumerable<string>> header in originalContent.Headers)
     {
         this.Headers.TryAddWithoutValidation(header.Key, header.Value);
     }

     this.Headers.ContentEncoding.Add(encodingType);
 }

 /// <summary>
 /// Determines whether the HTTP content has a valid length in bytes.
 /// </summary>
 /// <param name="length">The length in bytes of the HTTP content.</param>
 /// <returns>
 /// Returns <see cref="T:System.Boolean" />.true if <paramref name="length" /> is a valid length; otherwise, false.
 /// </returns>
 protected override bool TryComputeLength(out long length)
 {
     length = -1;
     return false;
 }

 /// <summary>
 /// Serialize the HTTP content to a stream as an asynchronous operation.
 /// </summary>
 /// <param name="stream">The target stream.</param>
 /// <param name="context">Information about the transport (channel binding token, for example). This parameter may be null.</param>
 /// <returns>
 /// Returns <see cref="T:System.Threading.Tasks.Task" />.The task object representing the asynchronous operation.
 /// </returns>
 protected override Task SerializeToStreamAsync(Stream stream, TransportContext context)
 {
     Stream compressedStream = null;

     if (encodingType == "gzip")
     {
        compressedStream = new GZipStream(stream, CompressionMode.Compress, leaveOpen: true);
     }
     else if (encodingType == "deflate")
     {
        compressedStream = new DeflateStream(stream, CompressionMode.Compress, leaveOpen: true);
     }

     return originalContent.CopyToAsync(compressedStream).ContinueWith(tsk =>
     {
         if (compressedStream != null)
         {
             compressedStream.Dispose();
         }
     });
   }
}

STEP 2: Create the handler

 /// <summary>
 /// A <see cref="DelegatingHandler"/> that handles encoding based on Accept-Encoding
 /// </summary>
 public class CompressionHandler : DelegatingHandler
 {
     /// <summary>
     /// Sends an HTTP request to the inner handler to send to the server as an asynchronous operation.
     /// </summary>
     /// <param name="request">The HTTP request message to send to the server.</param>
     /// <param name="cancellationToken">A cancellation token to cancel operation.</param>
     /// <returns>
     /// Returns <see cref="T:System.Threading.Tasks.Task`1" />. The task object representing the asynchronous operation.
     /// </returns>
 protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
 {
    return base.SendAsync(request, cancellationToken).ContinueWith<HttpResponseMessage>((responseToCompleteTask) =>
    {
        HttpResponseMessage response = responseToCompleteTask.Result;

        if (response.RequestMessage.Headers.AcceptEncoding != null &&
            response.RequestMessage.Headers.AcceptEncoding.Count > 0)
        {
           string encodingType = response.RequestMessage.Headers.AcceptEncoding.First().Value;

           response.Content = new CompressedContent(response.Content, encodingType);
        }

           return response;
     },
      TaskContinuationOptions.OnlyOnRanToCompletion);
    }
 }

STEP 3: Register the handler with the Web API pipeline:

 // In the Global.asax.cs or WebApiConfig.Register
 config.MessageHandlers.Add(new CompressionHandler());

Resources:

See the complete Web API pipeline here

[1] A thorough introduction on content negotiation can be found on Fillip W‘s blog: here – Note that this was written in 2012 when Web API had just come out with an RC so there may be places wherein the most recent version behaves differently.

[2] Gunnar’s blog on conneg: here [Caveat: 2 years old!]

[3] Creating a custom MediaTypeFormatter in detail: here

[4] Kiran Challa’s blog on creating a Compression Handler based on Accept-Encoding header here

Happy Coding!

Tagged with: , ,
Posted in .NET, ASP.NET, Gloabalization, http
  • Comic for June 28, 2017
    Dilbert readers - Please visit Dilbert.com to read this feature. Due to changes with our feeds, we are now making this RSS feed a link to Dilbert.com.