Tech blog

ElmahR is dead, long live RElmah!

Tue, 10 Apr 2018 17:53:47 GMT

ElmahR is my pet project, although I must say so far it's been much more successful than expected. It was really born as a playground to test and learn some new stuff, but it caught momentum, and it even received some contributions. It has about 30 forks on Bitbucket, and a few collateral projects using it or modding it have popped up. I'm pretty happy with all that!

But... It started more than two years ago, and the way I built it while experimenting new things made it grow in a way which wasn't really following a plan. I tried to keep it tidy and simple, but honestly there are portions of the code which are not as clean as I'd like, and they would need some major rethinking. Also, several of the features that I pushed into it are not actually so useful, so why keep them? And finally, the world has been running fast, delivering new libraries, or new versions of existing ones, at a very high pace which I was not really able to cope with. SignalR is the main issue here, ElmahR is still using v1.x, and moving to v2.x would be a breaking change. Furthermore, the task of writing a book did not really help with all that...

While I really want to keep ElmahR alive and actual, on the other hand the codebase really needs a lot to reorg to enable easy maintenance and addition of new needed features. There's no way I can do that while keeping backward compatibility and avoiding getting crazy...

So, I really see only one way to move forward: a reboot! And to make it clear that it's a real restart, I decided to rename it! It's a drastic decision, I love the ElmahR name and I'll miss it. Also, there's a concrete risk of loosing users with this move, and I'll try my best to prevent this from happening. But I think the reasons for doing such a move are stronger than the potential drawbacks. So be it: from ElmahR to RElmah!

Why RElmah?

It's a big reset, without backward compatibility, so I need to make that disconnect very clear. I do not want people to assume that a Nuget package update will automagically fix things...
It's a full redesign, which several concepts going away and several others added.
The name "ElmahR" was trying to express how the project was born (ElmahR = ELMAH + SignalR), whereas RElmah stands for "Reactive ELMAH", and it's putting the focus on the Reactive spirit this new version is willing to embrace.

So, I officially announce that the project is taking this direction, and in the next few months RElmah will gradually become available. The main features of this new project will be:

Github: ElmahR is on Bitbucket and I'm very happy with it, but I want to check if the Github community can bring more help to the project than it happened there
It will still be based on ELMAH and SignalR (v2), of course, but also on Owin and Rx on the server, and probably on RequireJS on the client
The code base will be simpler, streamlined, with fewer but stronger features: less is more :) Among them we'll have:
- application groups
- users per application group
- better organized server side, with a clean separation between the portion serving dashboard clients and a new "admin" one
- more fine grained configuration, with a better way to make it "live" and not just from web.config
- independent js client, cross domain
The dashboard will be redesigned on top of Bootstrap 3. I might switch from Knockout to AngularJS, but I'm not yet sure about that either

Ok, this is the plan, in the next few days I'll do a few early experiments before actually starting pushing stuff in its new repo. Stay tuned!

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.

The resultor pattern

Thu, 21 Mar 2013 05:00:24 GMT

In this short post belonging to the series about extending the world of Linq, I'll talk about an interesting way to leverage anonymous types through a pattern we use at work. We all know what they are, and we all know their most important limitation: once defined, an anonymous type cannot be passed to other functions or returned to the caller of the function which defined it (we are talking about language features, and we don't consider any technique based on reflection or other knowledge about the runtime internal structure of such types). It is quite common to write functions which return complex values, and if we want to make them reusable we need at some point to define some structure representing the result of the computation. We could use tuples, but they are not that good at communicating information, so we must surrender and define small DTOs just to represent those answers, just because anonymous type cannot cross the boundaries of a function. But is that completely true?

Let's suppose we need a function which parses string, and for each one we want to return a set of values. We could write something like this:

public static IEnumerable<DTO> Parse(
    this IEnumerable<string> source, 
    int someParam, string someOtherParam)
{
    return from item in source
           select new DTO
           {
               First  = item,
	       Second = item.Length,
	       Third  = new DateTime(2012, 1, 1),
	       Fourth = 42
           };
}

public class DTO
{
    public string   First   { get; set; }    
    public int      Second  { get; set; }    
    public DateTime Third   { get; set; }    
    public decimal  Fourth  { get; set; }    
}

The body of the Parse function is doing some stupid calculations, but that's not the point, what I want to show here is that for even for simple cases like this one we need to define a special class (DTO) just for the sake of returning four values for each parsed string. It feels like a "waste" of power. We need to define some static type to return our answers. And even more disturbing, it often happens that the caller does not really need all the values that we are returning, but just some of them.

But there is a way out. Type inference helps us to put a 'trick' in place and make anonymous types cross the function boundary. Let's look at our Parse function: each time it parses a string it 'calculates' 4 values and it packs them in our DTO to return them to the caller, but we could slightly change the point of view and say that the Parse function calculates those values and 'passes' them to the caller. This subtle change makes us think that we could do what we always do in such cases: call a function.

Let's change our Parse function signature like this:

public static IEnumerable<T> Parse<T>(
    this IEnumerable<string> source, 
    int someParam, string someOtherParam, 
    Func<string, int, DateTime, decimal, T> resultor)

In this new version we changed 2 things:

the return values is not an enumeration of DTOs (or whatever well-defined type), but IEnumerable<T>
the same T appears as part of the type of a new parameter we added to the already existing ones: this new parameter (a callback) is declared as a Func<...> with N+1 type parameters, where the first N types are the same types of the properties in the original DTO, and the last type parameter is T

This 'strange' signature is in fact very handy, and thanks to type inference we can modify our test call like this:

var parsed = from p in items.Parse(0, "wasp", 
                 (first, second, third, fourth) => new
                 {
                     First  = first,
                     Second = second,
                     Third  = third,
                     Fourth = fourth
                 })
             where p.First
                    .Equals("a", 
                            StringComparison.OrdinalIgnoreCase)
             select p;

The lambda expression we pass as the last parameter in the call defines an anonymous type, which thanks to type inference becomes the T of the generic Parse function. The complete body of Parse function could therefore be something like this:

public static IEnumerable<T> Parse<T>(
    this IEnumerable<string> source, 
    int someParam, string someOtherParam, 
    Func<string, int, DateTime, decimal, T> resultor)
{
    return from item in source 
	   select resultor 
           ( 
               item, 
               item.Length,
               new DateTime(2012, 1, 1), 
               42 
           ); 
}

It's very similar to the original version, but the new DTO() part has been replaced to a function call to the supplied Func<...> delegate, which is called resultor. So we now have moved the responsibility of creating a representation of our 'answer' outside of the Parse function, which now just calls someone capable of building such a representation. Thanks to type inference we can define the builder on the fly through a lambda, and use an anonymous type to contain the representation. We don't need the DTO class anymore, and one more advantage that we gain now is that we can easily handle cases where we are not interested in all the components of an answer. If for instance we just want to deal with the first and the fourth value, we can call Parse like this:

var parsed = from p in items.Parse(0, "wasp", 
                 (p1, _, ___, p2) => new
                 {
                     This  = p1,
                     That = p2
                 })
             where p.This
                    .Equals("a",
                            StringComparison.OrdinalIgnoreCase)
             select p;

I learned about this at work, and there we name it the resultor pattern. So far I did not find anything around describing this technique explicily, Bill Wagner in one of his books talks about something similar but in a more basic way. It adds one more piece to our toolbox which helps us move our coding more 'into Linq'. It could be used in other contexts too, but it really shines inside Linq queries.

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 current status

Sun, 11 Nov 2012 16:53:55 GMT

I've been quite silent about ElmahR on my blog lately, but that was just because I was taking some more rest than I usually do, I needed it :) This does not mean I did not do anything on the project, actually I added at least 3 interesting new features.

Asynchronous persistence

Errors persitence has always been intended as something important, but in a way less crucial that the error notifications. I never wanted to have failures during persistence get into the way of notifications, causing hiccups on that side. In order to achieve that I already introduced improvements in the past about how I was handling error happening inside ElmahR itself, but that was not the only way persistence could interfere with notifications. The other way was because persistence was happening synchronously with notification, and that could cause some issues. Now persistence happens asynchronously, letting notifications go out as fast as possible.

MongoDB persistor

Errors persistence has always been an isolated piece, and it was possible to replace it with different implementations, but there were not many options. I had an "in memory" implementation, which was there mostly for development reasons and could no really be considered trustworthy, and the "official" one based on Entity Framework. I already talked about why I choose EF, and in general this was because it allowed me to easily and quickly cover persistence over relational databases. But it's true that ElmahR persistence suits pretty well to the usage of document-oriented databases, so as a proof of concept I build a MongDB persistor. If you use Mongo you are good to go and persist your errors there, while if you use a different "NoSql" database you will find the MongoDBPersistor implementation quite useful to build your own for your target (and you might want to contribute it back when done ;) ). An implementation for RavenDB is on its way thanks to @gsuttie.

Error post encryption

Reacting to an interesting comment by I received on CodeProject, I added optional encryption when the ErrorPostModule sends errors info to a dashboard. Now you can specify a shared secret on both the monitored application and the receiving dashboard, if you do so messages will be encrypted. To do so is as easy as doing the 2 following things:

adding a secret attribute inside your errorPost section from the web.config of your monitored application
adding a corresponding secret attribute inside the matching application section from the web.config of your dashboard

Of course both attributes will have the same value specified. The Nuget package for the ElmahR.Elmah module has been updated to reflect this addition.

SignalR has gone 1.0 alpha

One last short thing about the fact that SignalR has reached the 1.0 alpha state, and it will be released as an official ASP.NET piece in the next ASP.NET Fall Update. I already started keeping an eye on it, as soon as it will be in a stable and complete status ElmahR will be updated accordingly.

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 low-level logging

Tue, 04 Sep 2012 20:03:29 GMT

Vacations are over, so I'm back working on ElmahR. In my previous post I already described what I've been doing to make ElmahR more robust, during the last weeks I've been going on developing those features. The most important feature I added is a new 'way' to launch an ElmahR dashboard. If you specify a log parameter on the query string, and you give it a truthy value (1, true, yes), like this:

http://elmahr.apphb.com?log=1

ElmahR will add a log window on top of the dashboard, and there you will see low-level logging messages appearing live. These messages might originate on both client and server side of ElmahR, and give you a way to have a fine grained level of detail about what's exactly happening in your setup. You could add ElmahR as an application feed as I explained the last time, and that's a more clean way to handle problems in a stable way, but if you are experiencing some unexpected behavior, and especially if you're just setting up your dashboard instance for the first time and things do not go smooth, this log can be very helpful in identifying what's wrong.

There are still a few things I want to add to ElmahR before considering 'finished', and I decided to publish them on a Pivotal Tracker dashboard, so if you are interested in them just have a look. If you think there's something that should be added and it's not listed there, open an issue on Bitbucket, or even better fork ElmahR, implement it and send a pull request, I'd be happy to discuss your ideas about it :)

ElmahR @ aspConf, it's been amazing!

Tue, 04 Sep 2012 12:14:31 GMT

UPDATE: the recording of the session is now available on Channel9 here!

It's been already one week, but yes, I did my session about ElmahR @ aspConf.net! I did not blog about it before because I really needed some rest, so every day since last week, after work, I've been just trying to relax and do some other stuff, but it's really been an amazing experience. It was my first talk ever in a conference, and starting from such a big one made me a little bit nervous, but everything went smoothly, my english was not too bad and I managed to stay in time. I had the chance to rehearsal my session at the company where I work a couple of days before, and I received some great feedback that allowed me to fine tune the contents just before the big day. I think that the final result was ok, and attending the talk you can have a pretty good idea about what's ElmahR and how it works. If you did not have any chance to attend it live and you're interested in the project, very soon the recording of the talk will be available on Channel9! They're publishing the videos day by day, so ElmahR should pop up any time soon, and in general a lot of great material came out from the conference, so check the recordings out.

It's been tiring, much more than I was estimating when I decided to answer the call for presentation. It's tough because you keep on fixing things and fine tuning the contents, it took me some time and I lost some sleep; but it's very rewarding at the same time, I received very good feedback so far and I want to thank all the people that found the time to help or to let their impressions afterward. And of course I want to thank all the guys that organized such a great conference, and all the other speakers that made it possible, it's been a pleasure to be part of it! :)

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! :)

Stuff about ElmahR

Sun, 01 Jul 2012 15:38:43 GMT

I decided to have a post about things happening around ElmahR. Lately people around blogged or talked about it, and those interactions are, or have been, available on the web, here I'll just collect them for (my) future memory :)

List updated on 01/07/2012

The Daily #nuget

The Morning Brew

Gregor Suttie's blog

ElmahR post about ElmahR

Brady Gaster session about Web API

Mentioning and showing ElmahR at the very beginning of the recording

ASP.NET Portal Home Page (!!!)

ElmahR appeared here on 13/06/2012 thanks to a reference to Gregor Suttie's blog, it will stay there for a few days and then it will go away, but still... :)

People hacking Elmahr

https://twitter.com/bitsprint/status/218731928583544832

Not bad :)

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.