February 2005 - Posts
Microsoft recently released 1.0 of the Enterprise Library. I was curious how the Logging block stacked up to Log4net.
Pros
- Configuration tool in the box - Slick little general purpose configuration tool used to configure all of the blocks in a consistent manner.
- Active development community - There's lots of buzz around the new MS library, unlike Log4net which is "incubating" over at apache with no releases since Beta 8 in 2003-07-15 ! (The Log4net developers need to get a release out...like...yesterday hint hint). Additionally there is Microsoft backing for Enterprise Library which can be considered a positive for the future of the library.
Cons
- No hierarchical configuration of categories - A nice feature of Log4net to be able to configure an entire hierarchy of loggers (if they are consistently named with dot delimited names) with a single switch rather than having to be explicit about every one. See Log4net's manual on Logger Hierarchy
- The tool restarts the web app on configuration change - When using logging in an ASP.NET web application, the configuration tool re-writes the web.config when you save configuration changings. This restarts the web app even though the changes were limited to the two logging configuration files that are external to web.config. Ideally you should be able to change log settings "in-flight" without restarting the web site, and rewriting the web.config seems to defeat the purpose of the file-watching that reconfigures itself when changes occur to these external configuration files. This is easy to work around by just editing the files by hand, but that sort of defeats the purpose of having a tool.
- No call-point short circuiting - There isn't a way to quickly determine whether logging is enabled at the call point to avoid unnecessary string building. It can be a big waste of time to concatenate or String.Format a large message string if it ultimately isn't going to be logged anywhere. See Log4net's FAQ for more information Log4net lets me write:
if (log.IsDebugEnabled)
{
log.Debug("Entry number: " + i + " is " + entry[i]);
}
- Priorities - This is minor, but I would have liked to see an enumeration of standard priorities in the block. The Priority parameter is just an arbitrary int. I guess this good and bad...good because you can choose any priority scheme you want, bad because it will be harder to enforce consistency among all developers (For example - 0 = Verbose for one group and 1 = Verbose for another.) You can't use System.Diagnostics.TraceLevel because the method of filtering on "MinimumPriority" is reversed, lower numbers are more verbose for zEntLib, higher numbers are more verbose for TraceLevel.
- Log4net appears to be much faster - In my testing, performance of the Enterprise Logging block was much slower than Log4net. Both on warm up time (the time it takes to configure the logging system and send the first log statement), and on logging 10000 messages in a tight loop.
| | Enterprise Library | Log4net |
| Warmup Time | 3014 - 5107 milliseconds | 100 - 161 milliseconds |
| Log 10000 messages | 9624 - 9814 milliseconds | 10 - 30 milliseconds |
Testing methodology - I wrote two equivalent empty appenders, one for Log4Net, and one for EntLib that do nothing but retrieve the log message into a string variable. This was done to completely factor out the cost of the appender, and hopefully measure the performance overhead of the logging framework itself. Then I wrote a console application that measures the warm up time and the time it takes to log 10000 messages in a tight loop. You can download the Visual Studio 2003 test solution from here I'd love to know if I've made an incorrect assumption in my test.
Votive for WiX
WiX now has a Visual Studio .NET Add-in. Continuing with the candle theme, it's called "Votive" and is available here.
"Votive is a Visual Studio 2003 extension. It allows you to create "WiX projects" that act like any other project in a VS solution. The WiX toolset is integrated in this install, so all you should need is this MSI an no other downloads from Source Forge. Unless, of course, you want to integrate the toolset into a build lab. In that case, I recommend just downloading the binaries .zip file.
Votive is mostly stable (shouldn't crash VS2003) but still lacks many features. Feel free to play with it, but don't be surprised if it doesn't behave the way you like. File bugs or Feature Requests on votive, and we'll see where it leads."
NAnt RC2
NAnt 0.85 just released RC2 here, as did NAntContrib here. If you're using earlier builds of NAnt get RC2 and run it through it's paces.
TraceTool 4
The Swiss-Army knife of trace viewing. I think this could be very cool, but I haven't had time to look into it yet. Article is here.
"A C#, Delphi and Java trace framework and a complete trace viewer (Tail, outputDebugString, eventlog) with support for Log4J, Log4Net and Microsoft Enterprise Instrumentation Framework (EIF)."
I've been using the slick little iehttpheaders tool to trace my browser's http traffic when troubleshooting issues. It logs out the requests, responses, cookies, HTTP headers etc... flowing back and forth. But the other day this MSDN article convinced me to spend a couple minutes looking at Fiddler, and I'm so glad I did. All I can say is Wow! This thing is going to come in handy. I wish I'd found it sooner.
One thing I really miss coming to ASP.NET from JSP is a mature application based Model View Controller framework like Struts and Maverick. From what I read this is a common refrain from former Java developers.
Our search continues for one that works nicely with the ASP.NET postback event model.
I've worked quite a bit with Maverick.NET, a little with Microsoft's UIP Application Block, and a co-worker just brought to my attention the NWAF project started by Natty Gur (overview article on codeproject here). I've also heard rumors that Visual Studio 2005 (Whidbey) has some sort of MVC in it, although I haven't looked into how they implemented it.
The stated goals of the NWAF project intrigue me, but the apparent stagnation of the project scares me off (no posts since July 2004). Anyone had experience with it?
Are there other MVC frameworks that slip into ASP.NET nicely out there? Should we roll our own? Should we just push to use Whidbey? Which one provides the best migration path to Whidbey? Ahh question, questions.
More Posts