Last time I wrote about Health Monitoring was during 2008 and since then I ‘m using, on a daily basis, a complex Health Monitoring EventLog provider to aggregate WebEvents from specific ASP.NET web applications.

Last year I found ELMAH (Error Logging Module and Handler) project and became a fan of the concept:

“[…] facility that is completely pluggable. It can be dynamically added to a running ASP.NET web application, or even all ASP.NET web applications on a machine, without any need for re-compilation or re-deployment.”

It didn’t take much time until I start thinking  about releasing a version of my EventLog WebEvents aggregator.

I’m now happy to announce that I finally made this project available at Codeplex and name it: ELWEA - EventLog WebEvent Aggregator for ASP.NET.

While different in nature this project main goal is pretty similar to the ELMAH project: keep an ASP.NET web application error tracking isolated and easily accessible.

What makes this project different from many other like ELMAH is the fact that it's not focused on handling and persisting error info. This project main goal is to aggregate all EventLog data belong to a specific web application under a specific EventLog source name.

Before

After

I’m sure that web developer and web site administrators will love it but I think that also IT pros that manage shared hosting environments will use it.

Visit here for a more complete description and here for the project documentation.

To make your live even simpler I’m planning to make a NuGet package available for ELWEA. Keep an eye on this.

Enjoy it!

From time to time I end-up finding really old hidden gems and a few days ago I found another one.

IList System.Collections.ArrayList.ReadOnly(IList list)

This amazing method is available since the beginning (.NET 1.0).

I always complain about the small support for ReadOnly lists and collections and I have no clue why I miss this one.

For those of you that have to maintain and extend legacy applications prior to ASP.NET 2.0 SP2 this could be a very useful finding.

I’m not used to use Finalizers in my everyday job but I always thought that if I use it more frequently I could achieve some extra performance.

Well, I’m a natural lazy programmer and that prevents me from digging deeper and doing some tests to clarify this guess.

Thanks to community, there is always someone ready to share knowledge and help those lazy guys like me.

One of those guys were Andrew Hunter that posted an article named “Understanding Garbage Collection in .NET”.

In is article I found that:

• The Finalizer execution is non deterministic – it depends on GC and the way it’s operating: concurrent or synchronous.
• It requires two GC cycles to completely remove the object and memory footprint.
• Two many objects with Finalizers could slow down GC a lot

This don't mean that we shouldn’t use Finalizers, but we must take same care when we create Finalizers. The simplified way to Finalizer usage is:

1. Implement System.IDisposable interface
2. move Finalizer code to Dispose method
3. Finish Dispose method execution with a GC.SupressFinalize() operation, this way the GC will know that this object wont need the Finalizer invocation and can be remove immediately.
4. Invoke Dispose method in Finalizer – this way we ensure that external resources were always removed.

A deeper understand on this procedure, also known as the IDisposable Pattern, can be acquired by reading this article (kindly pointed by Luis Abreu).

Conclusion

Using finalizers don't bring any performance improvement but it’s wrong use can be a vector for severe memory management problems.

When we have a class that own external reference not managed automatically by Runtime then the IDisposable Pattern should be used to ensure the correct memory cleanup.