NLog 2.0 Release Notes
NLog 2.0 has been released and is available for download from http://nlog.codeplex.com/releases/view/32639.
NLog can also be downloaded directly into your project in Visual Studio by using NuGet package manager. The following packages are available (use version 2.0.0.2000 or above):
- NLog - base package - installs NLog.dll
- NLog for Extended Profile - extended package for .NET Framework Extended Profile - installs NLog.Extended.dll
- NLog Configuration - configuration file for NLog
- NLog Schema for Intellisense(tm) - XSD file which allows editing of NLog.config with Intellisense(tm)
What is NLog?
NLog is a popular logging platform for .NET, Silverlight and Windows Phone with rich log routing and management capabilities. It makes it easy to produce and manage high-quality logs for your application regardless of its size or complexity. NLog is open source software, distributed under the terms of BSD license and source is available on GitHub.
NLog 2.0 release is focused on adding support for new platforms (Silverlight, .NET Framework 4, Windows Phone 7.x), improving logging architecture and manageability and addressing most frequently reported user issues.
What’s - New in NLog 2.0
- Asynchronous logging pipeline - fully supports async-only operations (Silverlight)
- Wrapper Layout Renderers - can transform output of other layout renderers
- New build system (MSBuild-based) - old build system based on NAnt is no longer supported
- New MSI-based installer - generated using WIX, NSIS-based installer is no longer supported
- Platform-specific Intellisense - includes only supported targets and properties for each platform
- Support for logging via Trace and TraceSource - new NLogTraceListener for integrating with legacy code
- New exception handling rules - logging configuration errors will now throw exceptions at startup.
- InstallNLogConfig.exe - new tool to install/uninstall logging objects (such as event log, performance counters, etc.)
- Exception logging enhancements - long-awaited extensions to ${exception} layout renderer.
- Support for .NET client and extended profile. All features which require .NET Extended profile have been moved to a separate assembly called NLog.Extended.dll. See the NLog.Extended project on GitHub for more details.
- Merged NLog.ComInterop into NLog.dll itself, which means one less DLL to deploy when using NLog through COM.
- GetCurrentClassLogger() is now supported in .NET Compact Framework.
Since there is no StackTrace class in .NET Compact Framework, the implementation uses relatively slow method to get the calling class, so using it in a loop or performance-sensitive code is not recommended)
- Lambda-based delayed message computation:
In addition to those, lots of work went into raising the quality bar of NLog:
- The entire codebase has been migrated to C# 3.0, cleaned up (thanks ReSharper!) and switched to using generic collection classes.
- StyleCop and FxCop are now being used to analyze code quality.
- Programmatic configuration API has been redesigned, to reduce internal coupling and improve testability
- Hundreds of new unit tests have been written
- Significant portions of internal logging and configuration pipeline have been rewritten for better maintainability.
- All supported platforms have fully automated unit tests now
Target updates
- Added WCF-based LogReceiverService target, for communicating between client which uses NLog and server. See examples on GitHub:
- Silverlight client which transmits logs to a web server.
- Log receiver service which uses WCF to receive logs.
- Update scrolling RichTextBox target - auto scroll, length limit, height and width configuration.
- Database target enhancements: support for installation and uninstallation, named connection strings from the configuration file.
- Mail target now supports enableSsl flag for communicating with SMTP server over SSL.
Compatibility
This release of NLog adds compatibility with several new platforms.
- Windows
- .NET Framework 2.0 SP1
- .NET Framework 3.5 SP1 - New in NLog 2.0
- .NET Framework 4 Client Profile - New in NLog 2.0
- .NET Framework 4 Extended Profile - New in NLog 2.0
- Silverlight (Windows/Mac OS X)
- Silverlight 2.0 - New in NLog 2.0
- Silverlight 3.0 - New in NLog 2.0
- Silverlight 4.0 - New in NLog 2.0
- Silverlight for Windows Phone
- Windows Phone 7 - New in NLog 2.0
- Windows Phone 7.1 (beta) - New in NLog 2.0
- .NET Compact Framework (Windows Mobile)
- .NET Compact Framework 2.0
- .NET Compact Framework 3.5 - New in NLog 2.0
- Mono (Windows/Unix)
- Mono 2.x profile (experimental)
NLogC component is supported on .NET Framework 4.0 only. NLog.ComInterop component is supported on all versions of .NET Framework. Compatibility with .NET Framework 1.x and .NET Compact Framework has been removed.
Backwards compatibility and breaking change policy
NLog v2.0 maintains backwards compatibility with:
- existing NLog.config files
- client code using Logger, LogManager, LoggerFactory, GDC, MDC, NDC and LogEventInfo classes
As a rule of thumb, existing code that does not rely on programmatic configuration or manipulation of NLog internal objects will continue to work with NLog v2.0. Majority of applications and components fall into this category and should be easily portable to NLog v2.0 without or with minimal changes.
Code which uses programmatic configuration will typically require modifications related to namespace reorganization.
Full breaking change policy can be viewed here.
Community support
Community support for NLog 2.0 is available through discussion forum at http://nlog-project.org/forum.
Bugs and other issues can be filed via issue tracker on CodePlex site.
At this time NLog project is not accepting source code contributions from the community. Users can help shape future releases by reporting bugs, suggesting new features and participating in community discussion on NLog forum.
Known issues
- NLog does not support running code in partial trusted on .NET Framework. Silverlight and Windows Phone partial trust scenarios are supported.
- NLogTraceListener is not fully functional under Mono because of platform differences
- Due to platform differences, on Mono, automatic flushing of targets when the application exits does not work properly, which may lead to a deadlock situation which prevents the application from closing. To work-around this problem, close logging configuration manually before program exits.