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!

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.

Microsoft has published a Security Advisory (2416728) about a security vulnerability in ASP.NET on Saturday, September 18th. This vulnerability exists in all versions of ASP.NET and was publically disclosed late Friday at a security conference.

Scott Guthrie has provided information on workarounds (please see Important: ASP.NET Security Vulnerability and ASP.NET Security Vulnerability) to prevent attackers from using this vulnerability against their ASP.NET applications.

To help with Microsoft’s response to the new padding oracle vulnerability, a new forum was also set up: Security Vulnerability.

Microsoft has now announced the release of an out-of-band security update to address the ASP.NET Security Vulnerability.

Applying the update addresses the ASP.NET Security Vulnerability, and once the update is applied to your system the workarounds Scott has previously blogged about will no longer be required. But, until the update has been installed, those workarounds must be used.

You can learn more about this security update release from this reading the Microsoft Security Response Center Blog Post as well as the official Advance Notification Bulletin.

Important Links:

• Important: ASP.NET Security Vulnerability
• ASP.NET Security Vulnerability
• Out of Band Release to Address Microsoft Security Advisory 2416728
• Microsoft Security Bulletin MS10-070 – Important