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.

Hi all,

At work we have about 5000 PC's that are mainly our commercial network. All those PC use intranet services and web applications.

Until a few months ago IE6 was our corporate browser (yep) but we ended moving to IE8.

A few days ago someone came to me saying that their application appears to have some problem because every time they click some HTML buttons the server gets two hits.

Also they are able to say that this didn't happen when they used the IE6.

In the faulty application the buttons that trigger two posts were System.Web.UI.HtmlControls.HtmlButton controls with Click event handlers registered.

After some research I found that the default type attribute value for HTML BUTTON element has changed in IE8 and later (here).

• In IE7 and earlier the default value is 'button'
• In IE8 and later the default value is 'submit'

This changed in browser default behavior was not reflected in the Server-Control that renders it: it doesn't set the type attribute value to button when a postback is required.

Without such change, every time we attached a Click event handler to a HtmlButton we endup with two posts: one triggered by the _doPostback function and another from the form itself (caused by the default type='submit' value.).

I easily bypass this problem by setting the type attribute value to 'button' in my base control.

Even so, I think that this change should be done by the framework itself when a postback is required in a HtmlButton.

After some 'reflection' I propose changing the System.Web.UI.Util.WriteOnClickAttribute method to do the job.

Such change would ensure the some behavior independent of the browser version.

If you have another workaround or you think I'm completely wrong please let me know.

Also if you think this is a real problem that should be solved then visit this Connect entry I create.