So I decide it's time to check out the Enterprise Library (http://msdn.microsoft.com/library/en-us/dnpag2/html/EntLib2.asp). The download (http://www.microsoft.com/downloads/details.aspx?FamilyId=5A14E870-406B-4F2A-B723-97BA84AE80B5&displaylang=en) and install go off without a hitch. What I'm really interested in is logging so I dig into it. Here's what I've learned (so far):
1) Although you get the source code, the installer will compile the library and you can use it pretty much like the framework.
2) Usage is very configuration oriented. A configuration editor is included. What this does is maintain the enterprise library sections of any app.config or web.config file; the rest of the file is left intact.
3) The logging block deals with the shortcomings of out-of-the-box framework 2.0 System.Diagnostics. The big problem with System.Diagnostics is that you need to format the message prior to sending it. But, if you're sending to say a flat file and the event log, there isn't a good format for both. The logging application block allows you to specify a formatter for most message destinations.
4) Gee, how many Microsoft developers would want one of the message destinations to be the Visual Studio output window? Makes you think Microsoft would include that as a destination. But no! Instead, they bury the source code for writing to the output window in the documentation and tell you to copy it into your project (see Walkthrough: Creating a Custom Trace Listener in the installed help file).
5) Having us copy what's really a small amount of code wouldn't be so bad if they gave us all of it. But they left out the namespace aliases. So, along with Microsoft's code you also need:
using System.Diagnostics;
using Microsoft.Practices.EnterpriseLibrary.Common.Configuration;
using Microsoft.Practices.EnterpriseLibrary.Logging;
using Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners;
using Microsoft.Practices.EnterpriseLibrary.Logging.Configuration;
6) Once you've created the class to send to the output window, you need to make the configuration tool aware of it. You do this by adding the definition for a custom trace listener and loading the assembly that has the class from above. This has a rather odd bug; you'd think you could load the assembly from anywhere on the local disk. But this causes the configuration editor to choke. You get a message telling to copy the assembly with the class to the same directory where configuration editor exe lives, which does solve the problem. Unfortunately, when the editor chokes, it corrupts the config file, so be careful.