(w)asp.net - signalr

SignalR Real-time Application Cookbook ready and available on stores!

Wed, 23 Apr 2014 19:45:06 GMT

I've been quite silent lately, but I really needed to use all my spare time for my last adventure: writing a technical book about Signalr! Well, the adventure is over and the book is now available on both the Packt online store and on Amazon.

It's been a very interesting experience, from which I learned a lot about how tough writing a book is :) And I also improved a lot my knowledge about SignalR itself.

I just want to thank Packt for the opportunity and their support through the whole process, and all the reviewers who helped me improving the content.

Now, some rest and then back to work. Next adventure? Probably ElmahR 2.0 :) And for sure I'll try to write more here, I've been neglecting this blog quite a lot lately...

New adventure: writing a book about SignalR!

Sat, 19 Oct 2013 09:35:29 GMT

After almost 2 years dedicating my spare time to ElmahR, now I'm giving it some rest while thinking about how to accommodate in a hypothetical v2.0 new ideas I have and new suggestions I received. In the meantime, I started a new adventure for the next few months: I'm writing a book about SignalR!

It's an interesting opportunity that PacktPub offered me, I never wrote a book before but I thought it could be a nice challenge. The book itself will be a relatively easy one to write, it's not about how SignalR works and its architecture, or about esoteric usage scenarios, it's a cookbook, a set of readymade recipes that readers will be able to apply with a small effort in order to tackle specific problems. This kind of content should fit both my limited spoken English and my SignalR knowledge, which is quite extensive (it's one if the pillars for ElmahR) but maybe not too "hardcore".

I'm already targeting SignalR 2.0, so this will give me an opportunity to update my knowledge to the latest release.

It will be fun, and I'll do my best to produce a book which delivers what it promises to.

ElmahR 1.1.5, ready for Azure!

Tue, 08 Oct 2013 17:29:05 GMT

Thanks to a notification I received here, I discovered that ElmahR was not behaving well on Azure, Actually the problem is a little bit fuzzy, and it has to do with the exact sequence used to initialize SignalR bits, but anyway I found some detail about the problem and, after tweaking a bit the way ElmahR bootstrap, I was able to patch it and deploy a new 1.1.5 version on Nuget.

Go and get it :)

ElmahR status, a new feature is enabling an interesting scenario

Wed, 28 Aug 2013 19:58:18 GMT

During the last few months I took a break from ElmahR, and I did not add any big new feature. I did some bug fixing and I added little things, but the last one I introduced in 1.1.0 is actually interesting, so I decided to talk a little bit about it.

It's been inspired by a feature request I received, and the resulting scenario is about connecting to an ElmahR dashboard which does not live under the same domain of the client code. The problem behind this is a well known one, and SignalR already handles it in a easy way to exploit. The problem with ElmahR was that I wasn't exposing that feature, but now with 1.1.0 you can specify if you want to enable cross domain requests by simply supplying a true value to the Bootstrapper.PreBootstrap() method, which must be called to startup the dashboard and it's usually called from the ElmahR.Core.cs file placed in the App_Start folder by the Nuget package.

With that support in place, it become fairly easy to connect the client-side ElmahR Javascript library to a dashboard living under a different domain. If you check out the ElmahR repository, you will find a new simple test web site called CORS, and the index.html page there will illustrate you how easily you can configure the library. The process is quite simple:

configure the dashboard paths as it's done in the index.html sample, of course using your specific dashboard address
call registerBuilder, which expects an object defining method which extend the elmahr global object; for example, if you want to receive errors notifications you'll need to redefine the notifyErrors callback; the code in index.html should be quite self explanatory
the new callback will be called at the right moment and each time you'll receive an array of errors which you'll be able to examine and manipulate

Everything described must be done when the DOM is ready. You can see which events are available on the client library looking at the source code here.

Finally, you might have noticed that the notifyErrors callback is defined with an object containing a member called replacer, this way we're instructing the elmahr object to remove the default callback and use this new one. If you prefer, you can keep the default callback and just append yours, in this case it is enough to specify your callback directly as the value for the notifyErrors member of the callbacks object, without any intermediate object.

On the issue tracker there are a few more interesting suggestions, I'm currently thinking about them and I might do some work to implement them in the next few weeks.

ElmahR 1.0!

Sun, 24 Mar 2013 17:56:52 GMT

Three months after my last port, this one is to announce that ElmahR has reached version 1.0! Last time I was not expecting such a long time to finish the latest "details", but some feedback I received (like this one) made me realized that I was still missing more modularity, and that has not been so easy to achieve. I had to deeply reorganize a lot of things in order to separate different concerns not only from a code perspective (that part was already fairly ok), but also from a packaging one. It's been though, but I'm very happy about what I achieved, and this allowed me to produce a set of new Nuget packages from which you can built a full ElmahR dashboard from scratch in Visual Studio, or add it to any existing monitoring application yo might have in place.

The ElmahR.Elmah package was already available, and was making easy to hook an existing application to a dashboard instance, but now we have several more to build a dashboard:

ElmahR.Core: this is the foundation of the dashboard, where posted errors are handled, associated to applications and broadcast to client, where all the necessary abstraction and related default implementations, are introduced, and where a basic streaming log page is deployed
ElmahR.Modules.Dashboard: this modules works on top of ElmahR.Core and add the full fledged SPA (Single Page Application) dashboard page I've been working on since the beginning of the project
ElmahR.Persistence.*: while ElmahR.Core by default keeps errors in memory without storing them anywhere, these modules let you persist errors on several different durable support
ElmahR.IoC.: the main module ElmahR.Core embeds an *IoC container (thanks to TinyIoC)to make dependencies resolution management easier and to integrate it with SignalR DepandencyResolver, this set of modules (so far there's only one implementation for NInject) will allow you to have more integration with your favorite container you might be using already

I also took advantage of this step to update ElmahR dependencies to the latest available versions, including the amazing official release of SignalR!

During the next days I'll try to write a few more blog posts about some (hopefully) interesting details, in any case I did a lot of work on the documentation, you can check it to understand how ElmahR works and for most of the configuration cases.

I'm very excited about this release, and now I'll hopefully take some rest, I'll keep on working on the project in order to fix bugs that might come up, and I'll be thinking about how to make it evolve in useful and interesting directions. I'd really want to thank a all the people who supported me with their feedback or concrete contributions, in particular Atif, the author of ELMAH, who I had the pleasure to work with and who supported me a lot especially at the beginning of the project, David, "SignalR man", and then Gregor, Nick, Ben, Carlos, and my wife :)

As usual, yo can give it a try here and check the source code on the repo.

ElmahR 1.0? Almost there!

Wed, 19 Dec 2012 20:04:05 GMT

It's been almost one year since I started ElmahR, and it's been a long journey, with a lot of fun and learning: I added a lot of features, which are described in my blog posts about the project, and probably many others could be added, but I think I'm getting near to what I'll release as version 1.0. In the last weeks I did some cleanup to the plugin system (which is not yet as good as I'd like, but it's good enough for now), and I enabled some "startup" statistics which allowed me to send down to clients numbers that apply not only to the errors received since the connections, but to the whole errors history. This means that now both the numbers related to the errors grouped by type and the errors piechart reflect the whole persisted errors history, which I think is a more useful information.

But what will bring me to do the move to the 1.0 release will be the SignalR 1.0 RTM (right now it is 1.0 RC1). I'm pretty excited about that and, as soon as SignalR will be officially released with the ASP.NET and Web Tools 2012.2 update (this should happen in January) I'll migrate ElmahR from SignalR 0.5.3, and when done I will align its version number. Can't wait to do that! :)

After that I think I'll take break from development and I'll spend more time in documenting it, I wrote a lot about it but the official documentation is not as much complete as I'd like. I will also try to write a new descriptive article about it, with the goal of updating the current one available in CodeProject.

So, stay tuned for 1.0 :)

ElmahR cleanup features

Thu, 20 Sep 2012 15:40:02 GMT

Latest additions

So, lately I've been working on features that improve the way ElmahR help you in maintaining ElmahR itself healthy. Earlier I improved the way it notifies about error happening in ElmahR itself, and lately I added a new feature that allows you to see how many historical errors have been recorded for each monitored app. It also let you clean up those error offering a set of 'trash bin' buttons which give you a (hopefully) easy way to clear ranges of errors that are not interesting anymore. Each application box has a new icon like this:

If you press it a popup window will appear, with all the details that I just described. It's more easy to actually try it than explaining it.

Future steps

I think that I will not add any particular new feature until I'll decide to go to 1.0, I will just go back to do some clean up which is there in the queue since a while, expecially regarding javascript and css, but also around the persistence server side code. I will also wait for SignalR to go 1.0 before going 1.0 myself, and I will also take my time to move the project to Visual Studio 2012. A lot of things to do yet, but mainly behind the scenes.

Keep on polling the project for the latest bits, and if you are using it please let me know, any feedback is welcome!

ElmahR 0.9.1 is out

Fri, 17 Aug 2012 15:46:59 GMT

I'm enjoying my vacations, and today I was having a nice, quiet and relaxing day at home, so at some point I said "there's no better day than today to fix some ElmahR bugs" :)

During the last few weeks I have been notified about a couple of problems with ElmahR, and at the same time I've been working on ElmahR internals to introduce some mechanisms to make it more robust and to give people an easier experience when installing it. ElmahR is doing quite good when dealing with errors from other applications, but it was still missing, for example, a good way to notify about errors happening inside ElmahR itself. You know, s**t can happen in any place, right? Let's suppose, for example, that we have a problem with the database where ElmahR persists errors, if we do not handle that case the right way the risk is that external errors don't reach the connected clients, and nobody will notice them. At the same time we had no easy way to know that such a problem occurred.

In theory I could have treated ElmahR as an errors source like any other application, and have it posting errors to itself through ELMAH and the ErrorPostModule, but that way it could have been easy to trigger infinite loops of errors. I needed something more directly targeting this kind of scenario, but at the same time the basic ELMAH strategy seemed to me the way to go: an HTTP module subscribing to the application-level Error event. That works quite fine when something happens during a regular HTTP request (i.e. when an error POST arrives), but it doesn't when SignalR hubs are involved. At the time of this writing, SignalR swallows any unhandled exception coming out of a hub public method, and this makes impossible to centralize any management of unhandled errors in an HTTP module. This problem will be solved in future versions of SignalR, so I decided to handle it with a 'quick and dirty' approach while waiting for some nicer way to do it. I added some exception handling logic in every public method exposed by my main hub, and the same logic is available in an HTTP module called ErrorTrapModule, which you can add to your configuration if you want to track error during regular HTTP requests. The result of this logic is that errors happening inside ElmahR are treated like errors coming from an external app, and it is possible to associate them to a specific error feed. You will need to do 2 things to your web.config:

add an application element inside your elmahr section to represent the feed of errors happening inside ElmahR
add the ErrorTrapModule to your HTTP modules

The result will be something like this:

...
<elmahr>
  ...
  <application name="Myself" sourceId="###ElmahR###" 
                             boxColor="boxColorElmahR" />
</elmahr>
<system.webServer>
  <modules runAllManagedModulesForAllRequests="true">
    <add name="ErrorPost" 
         type="ElmahR.Core.ErrorTrapModule, ElmahR.Core" />
  </modules>
</system.webServer>
...

It should be quite straightforward, we just have to pay attention to 2 small pieces:

the sourceId value is a special one, its value is ###ElmahR###, and such a value allows ElmahR to understand that this is a feed for internal errors; this default value can be changed to any other string with an additional attribute to the elmahr tag called selfSourceId, like this:
```
...
<elmahr selfSourceId="foo">
  ...
  <application name="Myself" sourceId="foo" 
                             boxColor="boxColorElmahR" />
</elmahr>
...
```
the boxColor attribute allows us to associate the box representing any feed with a specific CSS class, this way we can highlight special boxes like this one with any ad-hoc styling

This strategy is already available in the source code repository, and it works quite fine. It can be improved, I'll work on it, but it's already quite helpful. Such a system would have helped to easily spot the cause of the error happening in this first scenario.

I will also work some more on the client-side part of ElmahR, to make easier to solve problems when they happen there, but that's where thing could become more hard to grasp, and where only deep testing can really give strong guarantees. The second problem I was mentioning at the beginning of this post was actually caused by a couple of javascript problems. One of them was 100% my fault, and it's fixed, but the other one was because of javascript inconsistencies across browser versions. During the last few weeks I honestly did not spend much time in testing ElmahR on IE7/8, but one of the latest addition to the project (the plugins system) introduced a subtle bug happening only on those versions. Now it's fixed, but this will work as a good reminder for me about always testing on all the browser versions I want to support. Automated client-side testing will probably be one major step I will have to take soon.

While I was working on these problems, I also decided to follow @GregRatner advice, and now both the main solution and the sample setup zip contain an MVC source application, which will allow me to keep the testing phase more complete, and it will work as a sample for anybody wanting to monitor MVC apps with ElmahR.

PS: the bug related to javascript issues was at first appearing to be related to a problem with IIS 7.5, so in order to reproduce the issue exactly as described I needed to test it under Windows 2008 R2. I downloaded a test VHD from Microsoft, but then I discovered that it was not possible to run such a virtual machine with Virtual PC on Windows 7. That's where this post became very useful :)

Making ElmahR more rock solid

Mon, 13 Aug 2012 09:56:36 GMT

After the aspConf session I slowed down a little bit because I needed some rest, and right now I'm having some vacation, so my work on ElmahR is going on at a lower pace. As I mentioned in earlier posts and im my aspConf session, ElmahR is growing but it still needs some work to make it more error proof. ElmahR is about errors happening on monitored applications, but errors can happen inside ElmahR itself, no? In the latest days I started working on this particular aspect, and soon an ElmahR dashboard will be able to treat errors happening on the dashboard itself. You might think that this is not a problem: why didn't I just configure the dashboard to post errors to itself through ELMAH + ErrorPostModule? Well, that's possible of course, but it's also very easy to fall in cases where this scenario could generate endless loops of errors. Imagine you have a problem connecting to the database where errors are stored: when ElmahR receives a new error from a monitored source, it tries to store it and it fails, the error is intercepted, posted to ElmahR itself and received, then ElmahR will try to store this one too, and that will fail, and the loop starts again... A different approach is needed, and I begun to work on it. I already released some bits of it, but soon after my short vacation I will review a couple of details to make it cleaner, and I'll tell you more about the internals of this piece.

Switch off! :)

ElmahR and Appharbor: plugins and structure review

Sun, 01 Jul 2012 11:04:02 GMT

Last time I've been already mentioning the new Appharbor integration plugin I've been working on, but there's more to tell about it, mainly for two reasons: the plugin system deserves some more details, and along with the Appharbor plugin I completed a quite deep restructuring of the whole project, which actually makes much easier to start from a repository clone and build up a fully functional and customizable ElmahR installation with just a few clicks. Nothing is perfect, and actually these advantages come with a little more maintenance burden on my side, but so far I'm happy with it and when I'll have some more time I'll work on it. But first let's see more about the finished Appharbor plugin.

Appharbor build events integration

When you add a source application inside a dashboard, you know that you will receive there any unhandled exception occurring on the monitored application in real-time. In a context where applications are monitored for errors, probably you will have someone taking care of fixing them, and when fixed a new application version will be deployed. People monitoring the applications must be very interested in knowing when the mentioned deploys occur, and what this plugin makes possible is to have live notifications about the builds occurring if the hosting infrastructure is from Appharbor. The plugin takes advantage of the Appharbor HTTP API, and it's basically creating an endpoint where build events can be sent through HTTP POSTs by any service hook you may configure inside your Appharbor control panel. When those are received, a new SignalR hub packs and routes them to the dashboard, which the plugin enriches with some new UI elements where the messages end up stacking up, as for the error messages.

But how a plugin works?

Let's see how a plugin (which by the way is a new .NET class library, no surprise here) in the context of ElmahR project is composed by up to 5 components:

a server-side endpoint: a plugin might set up an endpoint where external system would send messages, such an endpoint should normally be built as an http handler where to POST data
a server-side hub: if the plugin is not about errors, it might need to deliver real-time communication events about different type of messages, therefore a new type of SignalR hub might be necessary; this piece is actually very easy because SignalR infrastructure already does all the discovery job, so adding a Hub-derived type inside the plugin assembly will do the trick
client-side logic: the plugin might need some javascript code to do its job on the client, and this will be mandatory if you have an additional hub sending stuff down to the client
client-side rendering: ElmahR is a visual dashboard, so quite likely a plugin will need to emit appropriate HTML, which could be created with whatever DOM manipulation strategy you like, but probably the easiest way would be to leverage the already integrated Knockoutjs support for this
client-side resources: images, css... those will be needed too, right?

Several of the just described pieces are straightforward, but there is one of them which is actually tricky: if you need to integrate new client-side visual widgets or processing logic, you need to integrate them inside a framework which must be totally unaware of the added plugin. That's obvious, a plugin requiring some manual intervention on the existing code or UI in order to be used is not really a plugin, but that actually poses a small challenge, because you'll need a way to add those pieces at run time, which also mean at the right time. Back to the Appharbor plugin, I needed to add a new messages counter for each enabled application, and also a container where to stack received build messages. It's similar to what happens for errors, but these are not error messages, so they have ad hoc data and visual representations. ElmahR is a Single Page Application, and that page is there unaware of plugins, how can we enrich it with new UI widgets? Believe it or not, it's again SignalR coming to rescue. Here you have the main steps:

I defined a few points inside default.cshtml where I might want to drop UI widgets, and I just put there divs with well-known ids
when a plugin wants to fill one of more of those extension points with its stuff, all it has to do is put cshtml extensors (that's how I call them now) files inside App_Data folder of the target dashboard, with a well-known subfolders structure (which I'll document as soon as possible); extensor are mainly pieces of Razor-enabled html, but thanks for some naming conventions in place they can also be blocks of javascript or css
when default.cshtml kicks in on the browser, it first does a call to a SignalR endpoint called commands, which is bound to a persistent connection that looks for extensors, compiles them through RazorEngine, caches them, and sends them back to the client
when the extensors are received, they are dynamically added to the DOM through jQuery
at this point the normal lifecycle starts, the SignalR hubs are initialized and Knockoutjs bindings are applied

Why using a persistent connection? As far as I know (and I might not know the whole story), SignalR initializes all the hubs at the same time with the call to the start() javascript method, and at that moment all the javascript callbacks must have been already added to the client side hub counterparts, so that SignalR machinery can register them. This means that a plugin must have a chance to add its javascript pieces before hubs start. The only way to use SignalR before hubs are started is using a persistent connection, which is not related to hubs infrastructure and can be used beforehand. Sequencing asynchroous client-side callbacks in an appropriate way, I've been able to guarantee that extensors get added to the DOM before hubs kick in, and to ensure that Knockoutjs bindings are applied as the last step. This last detail is also important, because it allows us to enrich our view models before Knockoutjs starts running, therefore plugins can take full advantage of the MVVM infrastructure in place.

This is been a very interesting pieces to build, and I could say more about it, but there one more piece that deserves more details now.

A new structure for the project

The plugins infrastructure brings several advantages, but in order for it to be effective the host must be of course unaware of any extension. This brought to my attention a problem that was already there since the beginning of the project, but whose importance became relevant just after these latest additions. ElmahR solution was made of a few libraries and a web application, which was setup to be up and running after a build with all the features enabled, and that was the way I arranged the solution because I wanted an easy and seamlessly way to deploy it to Appharbor, but this organization was also bringing some confusion to any people wanting to try themselves to setup an ElmahR dashboard for their infrastructure. The demo application was playing both source and dashboard roles, and despite to some documentation I wrote I had the feeling that this was not enough clear. The plugins made this even worse, and a reorganization became necessary. Now the project contains 3 web applications:

ElmahR: this is a dashboard with minimal configuration, ready to use and with no unnecessary configuration bits, hardcoded plugins or fake parts
ElmahR.SampleSource: this is a minimal web application which is there just to show how to raise errors and send them to a dashboard; it is already configured to talk to ElmahR dashboard just mentioned, making very easy to test things with no effort
ElmahR.Demo: this is a more complex setup, it's the dashboard hosted on Appharbor which is able to play as a set of sources and as an aggregating dashboard; its dependencies are declared directly inside the csproj file

When I say project, I do not mean a C# project, or a web application project, but I mean the whole ElmahR work in a more general sense. In such a way, the project is composed by 3 web apps, a few libraries and 2 solutions, one called ElmahR containing all the other pieces, and one called Appharbor which is the one the gets deployed on Appharbor infrastructure thanks to some naming conventions in place, and which contains only one web application, ElmahR.Demo. The project also contains all the bits necessary to build 2 Nuget packages, one for the ElmahR.Elmah assembly which exposed the ErrorPostModule, and one for ElmahR.Appharbor. Both can be found in the Nuget Gallery.

Conclusions

In the next weeks I'll try to write more formal documentation about all these things, for now what I want to say to close this long post is that it should be much easier for you to play with ElmahR code, and more straightforward to hack a repository clone for your need in your real infrastructure, and maybe to try to contribute back with interesting stuff. Just try and let me know :)

ElmahR 0.8.5 will be at aspConf!

Mon, 25 Jun 2012 17:15:15 GMT

Last time I blogged about ElmahR progress was less that 2 weeks ago, but to me it seemed much more than that, probably because I worked a lot on it, and amount of things I did made me feel those days have been longer. Most of the work I did has been 'behind the scenes' stuff, reorganizing projects and files in order to make room to new things, so if you will give it a try you will not notice big changes, but still there are a couple of new features, and the new structure will help a lot to build more of them.

But before going into details, I have to tell you that I'm really excited because I've been accepted as a speaker for the next aspConf! I'll be talking about ElmahR of course, but not because the project itself is really relevant, but because it's been a very interesting and challenging playground where to learn and experiment about what the ASP.NET platform and the web Open Source world give us today to build (hopefully) great and cool applications. If you feel you have a good idea, there is a lot of great stuff out there you can use to make it real, in my talk I'll try to expand on this showing those pieces in action inside ElmahR. It will be my first time as a speaker in a conference (and this is a BIG one), and I'll be surrounded by awesome speakers, I hope I won't be too bad. No pressure :) For more details go to the aspConf web site.

Appharbor integration

ElmahR is hosted on Appharbor infrastructure, which since the very first days has revealed as a very good place where to easily deploy it. Reading stuff about Appharbor platform I came to know a little more about their HTTP API, and one of the things I read made me think that I could build some more direct integration with their platform. ElmahR is about monitoring errors, and an errors normally implies building a solution for them and deploying it. Therefore I began finding interesting the way Appharbor allows you to configure a 'service hook' in your monitored application, in order to post info about how a build went when triggered. This way a dashboard user would know that a new version of the buggy app is available, and would therefore monitored it with different eyes :)

Looking at Appharbor docs it's been quite easy to build such a functionality, and now ElmahR supports this feature. Whenever your monitored application is hosted on Appharbor infrastructure, you can have the dashboard notified about build events related to that application, and have them displayed real-time inside the box associated to the source application. So far the implementation is quite basic, and most noticeable there is no persistence for build info events yet, but after some more code reorganization it should be quite easy to store them for future retrieval.

A plugin system, and related projects reorganization

ElmahR codebase it's always been very simple, we always had just a web application and a .NET assembly where the ErrorPostModule lives. But during the last week I reorganized it in a slightly more complex, but more flexible structure. Now most of the code of ElmahR moved in an assembly called ElmahR.Core, including things like the SignalR hub or the persistence system.

Why did I do this? I just told you about the Appharbor integration, that's indeed a very interesting feature, but to be honest I worked on it because it was a (good) excuse to find a way to build a plugin system into ElmahR. I started writing the new functionality first, and then working on it to extract it out in a way that I could get to the point where that piece becomes totally isolated to the rest of ElmahR, and easily pluggable, maybe soon with a Nuget package. And, by the way, that's the only way it would have made sense, having Appharbor related stuff hardcoded inside ElmahR would have been a too much strong statement, especially if your hosting platform is different. Reorganizing the code base has been a first step towards that goal, and having isolated ElmahR.Core helped with it, and it will in general do for future pluggable features.

I've been thinking a lot about how an ElmahR plugin should look like, and so far I identified 5 components:

server-side endpoint: a plugin might set up an endpoint where external system would send messages
server-side hub: if the plugin is not about errors, it might need to deliver real-time communications about different type of messages, therefore a new type of SignalR hub might be necessary
client-side logic: the plugin might need javascript code to do its job on the client
client-side rendering: ElmahR is a visual dashboard, so quite likely a plugin will need to emit appropriate (and possibly Knockoutjs-integrated) HTML
client-side resources: images, css... those will be needed too!

Working on this vision, I refactored out most of the Appharbor stuff into a new assembly (ElmahR.Appharbor), containing a dedicated endpoint and a specific hub. I said 'most of it' and not 'everything' because the client-side stuff is still in the main ElmahR projects, but that's just a matter of a more general reorganization of the whole solution, which is pending since a while and I'll try to achieve soon. If we forget about this last tiny detail, the plugin system works just fine, and actually it's been a very interesting piece to develop because it allowed me to learn more about SignalR, which in this context I used in a less conventional way: a content distribution system. Curious about this? Next time... :)

ElmahR 0.7.5

Wed, 13 Jun 2012 21:05:29 GMT

ElmahR reached today 0.7.5, with more improvements in several areas. Let's see them very briefly.

Settings Persistence

Now ElmahR is smarted and recognizes the current settings you have in place when you decide that you want to be remembered and tick the corresponding checkbox, while previous version was remembering only settings changed after ticking it. It also remembers about more things: as you might know you can reorder the application boxes as you like, now ElmahR records the positions you gave them and restores them when you reconnect. Persistence of error types status coming soon.

Connection status diagnostics

On the top right corner of your window you might notice messages appearing every now and then, those are giving feedback about things that SignalR does under the hood when dealing with connection glitches, those messages are there mainly for me for debugging purposes and to understand better what goes on, they should not get too much in your way.

SignalR groups, finally!

The latest version does a first network optimization thanks to SignalR groups. This feature allowed me to represent each monitored application as a group of connections. Each client is added to the corresponding application group when he/she decides to observe it ('play' button in app boxes), or is removed from the group when the user is not interested in that app anymore ('pause' button). Those settings are recorded as already explained, and both this stateful info and the tracking of user's current interactions with the dashboard allowed me to leverage SignalR groups, and send errors only to clients interested in observing the source applications. This could potentially save a lot of network bandwidth if monitored applications are a lot, and users selectively turn off uninteresting ones.

What about how I implemented this feature? Has it been difficult? Absolutely not, I just read the SignalR docs about it and applied it in the right places, it's been easy and quick to do :)

Test Exception

If you go to the demo website you will see nice skulls all over the place :) Each application can be enabled to raise ELMAH test exception, and when it is ElmahR shows a skull in the corresponding box, pressing it will issue a GET request for elmah.axd/test back to the source, which is a documented way to ask ELMAH to raise a test exception inside the monitored application, exception that should then be posted back to the dashboard. It's a useful way to test if things are configured correctly, if the exception does not popup you will know that something's wrong with your setup.

Summary

Many things are happening around ElmahR, the project is doing good (and slow) progress, and the community is starting contributing back with concrete pieces, like the help I received from the Nuget package, and feedback in form of feature requests or blog posts, like the one from @gsuttie that today made it to the official ASP.NET community home page! Cool! :)

But there's still a lot to do... wanna help? :)

ElmahR has its Nuget package

Wed, 06 Jun 2012 22:18:39 GMT

As already mentioned, a few days ago @gsuttie offered his help in building Nuget packages for ElmahR. We discussed and agreed that the most meaningful place to start was a package to easily configure a source, and he did a good job coming out with a first version. But then I soon realized that it would have been much easier to have the process more integrated with ElmahR project itself, taking advantage of all the Nuget packaging features. So I took over the task and finalized it, and now an 'official' Nuget package is available!

A few considerations:

The package is called ElmahR.Elmah, and it helps you configuring a source, adding the necessary pieces to your web.config
ElmahR is still under development, and the same stands for the Nuget package, which has the same version number of the currently available binaries (0.7.2). The package might not be perfect, if you discover anything weird in it please let me know
The package manages the dependency on ELMAH through Nuget itself
This package does NOT help you to configure a dashboad instance, for that you'll have to check the repository and start from there

In order to implement things easily and consistently, I went through an overall reorganization of the project:

The ElmahR.Elmah assembly, which was already there but mainly for technical reasons, now is a first citizen in the project because it absorbed the ErrorPostModule, which before was gently hosted by the Elmah Sandbox project. This change simplified the overall project maintenance and made easier to build a consistent Nuget package
I changed the .NET framework version of this assembly from 2.0 to 3.5, this way it will still work fine with ASP.NET 2.0 web site, but at the same time I've been able to take advantage of Linq while moving ErrorPostModule.

I'll write more about it in the next few days, probably in the project wiki.

Demo here.

ElmahR persistence is evolving

Mon, 04 Jun 2012 20:03:29 GMT

Quick update about ElmahR. After preparing the ground to support persistence, and building errors persistence on top of it, I went a step further, enabling a first draft of a simple 'user settings' storage system. The functionality if really a basic one, what it does is just storing a guid in a persistent cookie, and using that guid to associate a bunch of setting to the current user and store them inside the same database used for errors persistence, provided the user activated the functionality ticking the corresponding option. The implementation itself is not really worth many words, what's maybe more worth noting is the fact that this work is been the preparation for something more useful like profiling 'real' users connecting to ElmahR through whatever authentication mechanism you'd want to use. In fact the idea here is to let user authentication as an external piece, letting implementors choose the most appropriate one or maybe even write their own ways to handle the problem, ElmahR will just leverage IIdentity interface and all the related concepts to store settings.

At the time of this writing the system remembers for each user the status of each application feed, which can be 'running' or 'paused'. In the next steps it will remmeber more things, like the position of the application boxes on the left column or the status for the error types.

There's another interesting news, last week a parallel project about building a Nuget package for ElmahR source applications has been started thanks to @gsuttie, soon there will be goon news on that front too :)

As usual, you can give ElmahR a try here.

ElmahR persistence, and what about documentation?

Tue, 22 May 2012 20:27:04 GMT

My work on ElmahR is going on, during the last few days I've been adding useful features which I'll describe here briefly. Then I'll spend a few words about what's going to become more and more important very soon: documentation.

Persistence

Up to version 0.6 ElmahR dashboard life cycle was strictly related the the web application life cycle itself. As soon as the server was starting receiving error notifications, it would just accumulate them in memory. New clients connecting would therefore be able to receive 'old' errors only if still in memory on the server application. We all know that web applications can (and should) be recycled every now and then, that means that old errors can go away any moment. My idea about what ElmahR is has always been about a 'realtime' notification system, but it's true that a (short) historical time window can be useful, especially in the event of reconnections. We cannot trust the server application itself, so we need a system to recover historical errors. One way would be to go directly to the monitored applications, ELMAH gives us at least a couple of ways to look at old errors, so we could ask those details, but it's true that most of the times those kind of endpoint could be secured and not easily availables. So I decided to go the other way, implementing a persistence mechanism on ElmahR side.

The 'in memory' persistence was already implemented as a specific 'module', so it's been actually quite easy to build a new one persisting errors on a database table, which can be selected through configuration. To implemented I decided to go with Entity Framework, which is actually like using a bazooka to kill a mosquito :) I know that, the persistence here is really simple and it needs just one table with a bunch of columns, it would have been really easy to go with plain old ADO.NET or some simple data access library, so why use a fulll fledged ORM when I don't really have 'entities' to handle? I asked myself all those questions, but then I thought that this project is also a playground for me, and I was quite curious about using Code First and Migrations, so I gave them I try. It's been really easy and quick to implement the data access and I had the persistence up and running in a couple of hours, so I'm happy with my choice so far, knowing that there's always time to adapt this piece to another strategy.

Persistence actually helped to improve an already, but still quite new, existing feature which allows a user to ask for older errors on demand. On first connection ElmahR sends the last 25 errors he received, and the user can decide to ask for older errors, again in chunks of 25 messages. The previous 'volatile' persistence mechanism was not consistent across multiple connections, but now with more 'stable' historical data this feature works much better. Just scroll the page down to the bottom of the main errors feed and you will see how to ask for older errors. Check it out here.

Documentation

So we've reach version 0.7, there are still a lot of things to do but what's there starts being quite solid, with a number of features that I think makes ElmahR worth a try. What's really missing now is some more consistent documentation to actually implement a solution based on ElmahR. I've been blogging quite a lot about it, describing technical aspects of the project and showing configuration samples, but those info are not really organized in a way a user can easily and quickly go through them and figure out what's needed in order to have ElmahR up and running with no pain. So that's my next step, write some simple and straightforward docs to help you out there using ElmahR along with your applications. Stay tuned here and on the repo :)

Upgrading ElmahR to SignalR 0.5

Wed, 16 May 2012 20:42:07 GMT

During the last two weeks I've been quite busy at work, so I haven't got many chances to go on implementing new on ElmahR, I've been just able to dedicate small time slices to the project and I used them to do mostly housekeeping. One of the things I did was to upgrade SignalR to version 0.5. SignalR is evolving quite fast so I wanted to keep in sync with it, I already knew that I would have had to fix a couple of things in my code because of breaking changes that 0.5 introduced, but those have been very easy. Everything was working fine so I deployed it on the demo site, but there something unexpected started to happen, the error feeds started getting filled by a recurring exception saying that 'ElmahR.ElmahRHub' hub could not be resolved. I immediately thought that something must have changed in SignalR, and that someone around the world was having a browser window open and pointing at the demo, but because that window was using an older version of SignalR javascript pieces the server was not able to understand those 'pollings', and therefore it started raising an InvalidOperationException.

It was already late night, so I just thought "those browser windows will be closed soon" and I did not worry that much, I just twitted about the new version and I went to bed. But the day after the errors were still popping up, and at a higher frequency, and every time I was connecting to check I could observe those exceptions bloating the error feeds.

David Fowler from SignalR team noticed it too and immediately pointed me at the problem, they effectively changed something in the SignalR protocol and so far there is no versioning mechanism for that, but they should work on that piece for the next versions. That is good news of course, but I still had the problem. I was really thinking that it wouldn't have last that much, but it's been a surprise to see how many people around have been using, and still use, the demo website to see how the project goes :) The bad part of this is that many of them are returning visitors with cached versions of the SignalR 'end point', making the application raise those exceptions.

The first thing I thought I could do to minimize the problem was to add an ELMAH filter to trap and discard those specific errors, but then I realized that another approach was probably more suitable to this case. If 'old' clients are connecting, I would really want to opt them out, so what I thought I might do was to 'cut' their path to the demo. When you use the hubs from SignalR, you must reference a dynamically generated javascript piece at signalr/hubs, but luckily since 0.5 of SignalR this path is customizable. So I decided to add myself the piece SignalR is still missing: protocol versioning, through the end point. How? Easy, I just customized the path to be signalr05/hubs. To achieve it I just had to do 2 things:

go to global.asax.cs, and in the Application_Start handler add a route like this:
```
RouteTable.Routes.MapHubs("~/signalr05");
```
change the references (just 1 place actually) to the dynamic javascript path with the new one ('signalr05/hubs')

Now the demo works fine again, the errors have disappeared and the 'old' clients are blocked but they will work again as soon as they refresh the web page. This problem will be probably solved in future versions of SignalR, but for now this is a quick, clean and easy way to work around it. If you are planning to upgrade SignalR to 0.5 you may find this fix useful.

ElmahR v0.6

Wed, 02 May 2012 18:52:14 GMT

ElmahR reached v0.6, and a lot of improvements happened since previous version, most of them on the UI. Finally we had time to concentrate on the visual aspects of the dashboard, trying to come up with something more reactive, better at bringing the right information and at scaling along with the number of monitored applications. This last issue has been worrying us the most, it's not easy to accomodate the potentially quite big volume of info that ElmahR handles. We let ourselves be inspired by Twitter web site user experience, and we took advantage of the Twitter bootstrap framework to build a responsive layout. It is a very interesting framework, it allowed us to greatly improve how the dashboard looks like, and now we have better support of different form factors and browsers. Now IE9 is well supported too, while we still have problems with older versions, we'll try to target IE7 and IE8 in next iterations. Twitter bootstrap is quite simple, but it can also help deliver sophisticated UIs and to do that it can get pretty complex. We cannot really say we understood everything of it, but we also wanted to deliver soon, so we found a quite good and quick compromise analyzing a sample application and modifying it to our needs. You might notice it in the css files, one of them is still quite 'in progress' and it also contains stuff coming from the original sample and that we do not really use, but it's like that because we'll try to understand more of it in the next days.

Should you try the demo web site, you will notice that we have a responsive layout, normally composed of 3 columns which collapse to just 1 when the available width goes below a certain limit, as it happens on a phone. The first columns is composed by summary boxes. The first box shows overall info like the total number of errors, info about the latest error and the name of the application which raised it. The remaining boxes are similar, but specific for each monitored application. Those app-specific boxes are sortable by dragging and dropping them, they can be expanded to show the errors belonging to each of them, and the relative error feeds can be paused or resumed. The second column is a global feed where all the errors are stacked up, the newest ones being on the top, this column let the user know about the latest errors occurred at a glance. Each error is expandable to see full details in a popup, which is disabled when the dashboard runs on small form factors because we're still looking for a better way to show details on those kind of devices. The third column is intended to host additional pieces, so far we built 2 statistical 'plugins' which should be considered samples about how to build such extensions, this area still needs more exploration but it's working quite fine and could be already leveraged to augment the info ElmahR gives to its users.

With this release we'll leave the UI alone for a while, and the efforts will move to the server side. There are a lot of interesting SignalR features that could be used to improve ElmahR efficiency, the most notable being 'groups', so part of the energies will be allocated to further investigation on this amazing library. The new UI introduced a few new usage 'idioms' that would take advantage of some server side improvements, like user profiling and smarter errors buffering, so these will be the areas where most of the work will be done in the next few weeks. I'll also try to blog more about the work process and the concrete code, I admit I'd like to have ElmahR evolve in a way that people would consider it a 'good sample app' for libraries like ELMAH, SignalR or Knockoutjs. I cannot say when (and if) this goal will be reached, if some of you guys out there want to help me in this effort (even simple advices or suggestions are very welcomed) I'd be glad to try with you :)

People like ElmahR!

Tue, 17 Apr 2012 20:11:50 GMT

Yesterday I blogged and twitted about the v0.5 release of ElmahR, and after a few retweets an amazing sequence of interactions started to happen! In the last 24 hours I received many retweets, new Twitter followers appeared and my tweet has been favorite by several people. The demo web site received hundreds of simulated errors (which actually helped me to spot at least 2 bugs :) ), my blog post has been visited by more than 400 unique visitors, and ElmahR repository has 4 new followers. And there's more, I became member of the Software Development list, and today ElmahR was on the home page of The Morning Brew, and in a very good company indeed! Those are not particularly big numbers for most of you, of course, but for me they are :)

I'm pleasantly surprised by the reception that ElmahR has been given by the community, I had the feeling that it was an interesting idea when I first developed it, but it's only after such reactions that I realized all the work done so far has been worthwhile. This of course raises the expectations, and now I cannot really screw it up :) I'll do my best to do the right moves now in order to deliver the value which such a tool is supposed to give. At the same time I would really like to make ElmahR a project driven by the community, and contributions would be really welcome. In the next days I'll try to go on implementing stuff and refining the UI, at the same time I'll be working on a clear enough roadmap, and I'll be trying to identify the steps, the procedures and the tools which would help in making ElmahR a community project. It's all new to me, but I'll try to do my best.

So, see you soon :)

ElmahR v0.5

Mon, 16 Apr 2012 20:55:17 GMT

ElmahR v0.5 has just been pushed on the demo site and in the source repository. A global errors feed has been added, and now the applications resume shows for each source what the last error has been and how many errors have been raised.

The amount of information starts getting big, and potential UI scalability problems are clear, so this release has been an intermediate step towards a new layout. This will be the next step, a more Twitter-like applications, I'll blog about it in details when ready (hoping to get there in a couple of weeks...).

ElmahR v0.3

Thu, 22 Mar 2012 23:10:06 GMT

Short post, I just pushed v0.3 of ElmahR in the source repository. This release has been about Javascript cleanup, making code much more modular and with a draft plugin structure. I also update jQuery to 1.7.1, and introduced RequireJS for handling dependencies, but so far I just played with it and it's not yet used, this will happen in the next days along with some UI improvements. After that I'll improve the HTTP traffic between client and server, adding more but optimized roundtrips, and then I'll move to work on the server side of the system.