So last time around we built together a small p2p chat app using WPF and ASP.NET Web API. Today, we are continuing our experiments with ASP.NET Web API and setting up a simple push (or push-like) messaging system between different apps using self hosting.

In fact, we’ll use one app (“server”) to push out messages to a number of other apps (“clients” or “subscribers”). Even though we have the (in)glorious WCF callbacks at our disposal, I thought it might be fun to try it that way. Hopefully, that sounds interesting, or at least intruiging. In the process we’ll also serialize custom types to JSON using JSON.NET and pass them between self-hosting applications.

Recently I’ve been really enjoying myself with ASP.NET Web API. It is a tremendous beast, and with it’s self-hosting capabilities, it’s suitable as an HTTP-channeled-communication not only for ASP.NET websites, but also for any other .NET applications. In this post, I’m gonna try to show you the outcome of my weekend mash up – a peer-to-peer WPF chat application (clients connect directly to each other), fueled by ASP.NET Web API.

Recently, I’ve been playing a lot with ASP.NET Web API, as it is really an exciting technology. It works exceptionally well with JSON.NET (Henrik Nielsen wrote a great post on how to return JSON from ASP.NET Web API using JSON.NET).

However, as it’s been the case in the past with i.e. WCF, I’ve run into a issue with serializing Entity Framework object to JSON when returning them from the ApiController. This is not, by any means, an issue in ASP.NET Web API, as the problem in this case lies in the EF lazy loading, which causes circular reference between the objects. This then throws a corresponding error – “A circular reference was detected while serializing an object of type (…)” if you are using JavaScriptSerializer, “Self referencing loop detected for type (…)” if you are using JSON.NET and so on.

I thought it might be useful to remind about possible solutions to this. There is an easy workaround.

I’m convinced that most of us web developers often have to struggle with some sophisticated Javascript driven UI that tend to get out hand with their complexity, dependencies and relationships.

With that in mind, I wanted to show you an example of a knockout.js code in action.

Since knockout.js is one of the most amazing and innovative pieces of front-end code I have seen in recent years, I hope this is going to help you a bit in your everday battles. In conjuction with Last.FM API, we are going to create an infinitely scrollable history of your music records – just like the infinite scroll used on Facebook or on Twitter.

Whenever handling an event in jQuery, be it a UI event or a programmatic event, it is very often required to pass some piece of data to it. It is common for novice developers to pull that data directly from globally scoped objects – variables or global DOM selectors – which is not the best practice, and with more sophisticated dynamic UIs it easily gets out of hand and becomes impossible to maintain in the longer run.

To avoid such issues, jQuery provides two easy mechanisms for passing data to event handlers. More after the jump.

A while a go, the C# community got surprised by another GOTCHA, discovering that using a foreach iteration variable inside a LINQ query, may not always yield the expected results. The variable gets captured by the foreach loop and, due to the evil work of closure, it remains scoped outside of the LINQ query itself living its own life so to speak. This has now been corrected in the Visual Studio 11 Beta.