Scott on Writing

# re: Scott Hanselman's Recommended Tools 6/29/2005 10:39 AM Kristopher Cargile

Scott's got an excellent list of tools on his site. I also maintain a list (albeit without the high-caliber descriptions Scott has given us) of development tools on my blog, most of which are free. Take a look and let me know what you think!

# re: Scott Hanselman's Recommended Tools 6/29/2005 11:34 PM Greg Gamble

For text work, I use TextPad. It'll compile and run Java directly; and has syntax highlighting for any language you can think of. One of my "must have" programs.

# re: Scott Hanselman's Recommended Tools 6/30/2005 2:57 PM Brian

Why would you use the ELMAH over the Exception Handling Block that Microsoft provides? I'm new to .net too and the Exception block was recommended by someone who has been doing .net for years.

# re: Scott Hanselman's Recommended Tools 6/30/2005 7:58 PM Scott Mitchell

Brian, the thing I like most about ELMAH is that it's created as an HTTP Module, which means you can just take it and "plug it into" your ASP.NET application by adding the DLL to your /bin directory and adding a few lines of markup to your Web.config file. No recompilation or whatnot is needed.

ELMAH isn't designed to necessarily replace the Exception Handling Application Block (EHAB), rather it illustrates how to make pluggable components using HTTP Modules and shows the maintainance advantages therein. See the article Atif and I coauthored for more info on this concept and details about ELMAH - http://msdn.microsoft.com/asp.net/default.aspx?pull=/library/en-us/dnaspp/html/elmah.asp

As I said in my blog post, ELMAH's so easy to setup and use that it's one of the first things I add to any new project. Plus, since I get a detailed email whenever an unhandled exception happens, I can oftentimes fix a bug that a client finds when testing before he can even finish writing up an email to me explaining said problem.

# re: Scott Hanselman's Recommended Tools 7/2/2005 1:38 PM Brian

Sounds like the winner. I read the Exception Handling App Block document and review their code. It requires an import on each page and a custom provider to send emails or do anything other than add to the event log. I also investigated the Data Access Block and it seems to be involved as well and is not 2.0 compatible as yet. MSFT said the next Enterprise Library will be 2.0 ready so I guess I'll wait. Thanks for the info and not just a RTFA reply ;-)

# re: Scott Hanselman's Recommended Tools 7/8/2005 8:51 PM Scott

I just looked at the ELMAH article, and it looks great. I'm curious, do you need to set up the Server SMTP address information? Thanks.

# re: Scott Hanselman's Recommended Tools 7/9/2005 1:20 AM Scott Mitchell

Scott, the SMTP settings in ELMAH are optional. If you want to automatically receive an email when an unhandled exception occurs then you need to provide said information, otherwise you can omit it.

# Watch Your Cookies! 7/18/2005 5:14 PM Scott on Writing

# re: Scott Hanselman's Recommended Tools 7/29/2005 5:07 AM Atif Aziz

Scott, the SMTP server address is one of those settings that cannot be setup in ELMAH and deliberately so. The rationale for this was laid out in a message board thread [1] over at the GDN Workspace for ELMAH [2]. I've included the response here for sake of convenience (apologies to the owning Scott [man, too many Scotts are in the house]).

"The SmtpServer property is a static property, meaning that its value applies globally to the entire AppDomain. ELMAH is like a "third-party" library to the application and if each such library were to set this property according to its configuration settings then they’d basically end up competing and stepping over each other. A little common sense, however, tells us this does turn out to be somewhat of a superficial concern because a sensible setup would have all libraries use the *same* setting. To be on the *technically* correct side, on the other hand, libraries should never touch global and static properties and leave it up to the application to set them up during start-up. In the case of ASP.NET, this would mean setting it in the Global.asax during Application_Start. It’s really the right place because it would then apply to all parties concerned with sending mails. This is one of the only areas (at least know to me to date) where deploying the e-mail module from ELMAH may require a change to application code. This is really an unfortunate side effect of the static design of the SmtpMail class. You can gain some hope using the Fields property on the MailMessage since it can be exploited to set the SMTP server on a per message basis. The downside here is that the solution would then only work on ASP.NET 1.1 since the Fields property was not there in 1.0. I didn’t want to leave out people who may want to eventually use ELMAH with ASP.NET 1.0. I guess I could use conditional compilation such that the feature would only work on ASP.NET 1.1, but that seemed ugly in the face of binary or type compatibility. There may exist a more elegant solution that could take advantage of JIT or dynamic assembly loading, but I dropped both those avenues to keep ELMAH digestible for the online article."

[1] http://www.gotdotnet.com/workspaces/messageboard/thread.aspx?id=f18bab11-162c-4267-a46e-72438c38df6f&threadid=64b1e0c3-8022-4f0b-b4e7-2bac55f591a8
[2] http://workspaces.gotdotnet.com/elmah