log4net 1.2.11 is not only a bugfix release, it also adds support for Microsoft® .NET 4.0 as well as the client profiles of .NET 3.5 and .NET 4.0.
Starting with this release log4net uses a new strong name key but we also provide a binary distribution using the "old" strong name key of log4net 1.2.10 and earlier. See the FAQ for details.
The binary distributions no longer contain assemblies built for the Compact Framework 1.0 or the Shared Source CLI - you can build those yourself using the source distribution.
The signature of ILoggerFactory.CreateLogger has changed.
Renamed namespace log4net.spi to log4net.Core. Renamed namespace log4net.helpers to log4net.Util.
In the log4net.Config namespace the DOMConfigurator, DOMConfiguratorAttribute, DomainAttribute, and AliasDomainAttribute have been marked as obsolete. These types are still available and functional in this release.
The XmlConfigurator and XmlConfiguratorAttribute types replace DOMConfigurator and DOMConfiguratorAttribute. The RepositoryAttribute and AliasRepositoryAttribute types replace DomainAttribute and AliasDomainAttribute.
Renamed AdoNetAppender, AspNetTraceAppender, SmtpAppender, Iso8601DateFormatter, MdcFilter, and NdcFilter. Note that the config file type resolver is case insensitive so this is only a breaking change for code that programmatically creates a type that has been renamed.
A new log4net assembly is built that targets all CLI 1.0 compatible runtimes. This build is essentially a common subset of the Mono 1.0 and .NET 1.0 builds. It is built using the MS .NET 1.0 compiler and libraries but does not use any platform specific APIs.
This build is only available in release configuration and can be found at bin\cli\1.0\release.
Logging contexts can be used to record contextual data that is relevant to the current process. Logging contexts are both an extension of the concepts embodied in the MDC and NDC and a replacement for them. The MDC and NDC have been reimplemented to use the ThreadContext as storage.
The logging contexts provide a single unified view that cuts across different scopes within an application. The contexts are layered in the following order of narrowing scope: GlobalContext, ThreadContext, LogicalThreadContext, and LoggingEvent. Context values specified in a narrower scope hide the matching value in a wider scope.
The PatternLayout now supports long pattern names. These pattern names are significantly more readable than the single character patterns.
The PatternLayout now supports custom patterns. New patterns can be defined in the config file:
<layout type="log4net.Layout.PatternLayout">
<converter>
<name value="myConverter" />
<type value="TestApp.MyPatternConverter, TestApp" />
</converter>
<conversionPattern value="%-5level %logger - %myConverter - %message%newline" />
</layout>The above config defines a custom pattern called myConverter which is bound to the TestApp.MyPatternConverter, TestApp type. This type must extend the log4net.Util.PatternConverter base class. The custom pattern can then be used in the pattern string.
For full details see the SDK Reference entry: log4net.Layout.PatternLayout.
A new pattern based type, PatternString, can be used in the config file to set string properties using a pattern syntax. For example the File property of the FileAppender could be set as follows:
<file type="log4net.Util.PatternString">
<converter>
<name value="folder" />
<type value="TestApp.SpecialFolderPatternConverter,TestApp" />
</converter>
<conversionPattern value="%folder{LocalApplicationData}\log-file.txt" />
</file>The code for the SpecialFolderPatternConverter is as follows:
public class SpecialFolderPatternConverter : log4net.Util.PatternConverter
{
override protected void Convert(System.IO.TextWriter writer, object state)
{
Environment.SpecialFolder specialFolder =
(Environment.SpecialFolder)Enum.Parse(typeof(Environment.SpecialFolder), base.Option, true);
writer.Write(Environment.GetFolderPath(specialFolder));
}
}For full details see the SDK Reference entry: log4net.Util.PatternString.
The XmlConfigurator methods now support loading the configuration data from a URI. Config can be loaded from any URI supported by the System.Net.WebRequest class.
Log4net supports configuring No-Touch deployment applications using the XmlConfiguratorAttribute. If a relative config file or extension is specified then this is resolved relative to the deployment URI.
The config file parser has been enhanced to support specifying the property subtype, or intermediate type, directly on the property element, for example:
<layout type="log4net.Layout.PatternLayout" value="%message%newline" />
Implicit conversion will be attempted between the value string and the type specified, and then again between the type and the target property type.
Added .NET String.Format style formatting syntax methods to the ILog interface. The new methods are: DebugFormat, InfoFormat, WarnFormat, ErrorFormat and FatalFormat.
Levels are defined by the repository LevelMap. The defined levels, the relative ordering of levels and level display names can be configured on a per-repository basis.
Appenders that interact with controlled platform resources, e.g. files, can be configured to use a separate security context when accessing these resources. The calling thread may not have appropriate privileges to access the resource a custom SecurityContext can be used to elevate the privileges of the appender. The WindowsSecurityContext is used to specify alternative credentials on the Windows platform.
The AnsiColorTerminalAppender writes events to the application's ANSI terminal window. It can be configured to specify the text and background colors for different level events. Note that Console applications running on Windows do not have an ANSI terminal window and should use the ColoredConsoleAppender instead.
Logs events to a local syslog service. This appender uses the POSIX libc syslog library functions. If these functions are not available on the local system then this appender will not work!
The RemoteSyslogAppender uses the BSD syslog protocol to log to a syslog daemon. The syslogd listens for for messages on UDP port 514.
The TelnetAppender accepts socket connections and streams logging messages back to the client. The output is provided in a telnet-friendly way so that a log can be monitored over a TCP/IP socket. This allows simple remote monitoring of application logging.
Added LoggerMatchFilter which matches a string against the event's logger name.
The FileAppender (and by extension the RollingFileAppender) now support pluggable file locking models. The default model, ExclusiveLock, maintains the current exclusive file locking behavior. An alternative model, MinimalLock, can be used to support writing to a single output file from multiple processes.
For full details see the SDK Reference entry: log4net.Appender.FileAppender.LockingModel.
The RollingFileAppender now supports a new rolling style, Once. In this mode the appender will roll the file once per run.
On the .NET 1.1 platform only, the SmtpAppender supports authenticating against the mail server using either username and password or integrated NTLM authentication.
Sends events from a ThreadPool thread rather than the calling thread to prevent transfer, and potential loss, of the CallContext.
Fixed date rolling period detection for non UTC timezones.
Updated to support writing more than 30,000 chars in a single message. Fixed background color overspill if the console window needs to scroll the contents.
The build output is now log4net.dll for all frameworks. This is a breaking change.
To resolve cross platform and cross version issues we have changed the log4net assembly to use a common name for all frameworks. The assembly friendly name is now log4net. The builds for each framework can now be differentiated by the assembly title. This includes the name of the framework that the assembly was built on.
The Release and ReleaseStrong builds have been consolidated into a single build called Release. This Release build is strongly named.
The ColoredConsoleAppender writes events to the application's console. It can be configured to specify the text and background colors for different level events.
The SmtpPickupDirAppender generates SMTP compliant messages and writes them to a local directory. These files can then be read by an SMTP agent (e.g. the IIS SMTP Agent) and delivered.
This new layout formats the logging events as XML which complies with the Apache log4j™ event dtd. This can be used to transfer log event from log4net to log4j. Currently the only appender that can communicate directly with log4j is the UdpAppender.
Added support for capturing the current thread principal name and the app domain friendly name for each logging event.
All types specified in the configuration files are now loaded using a case insensitive method.
The LoggingEvent now supports fine grained fixing of data that needs to be accessed outside the append context, e.g. when an event is buffered. The new Fix property takes a combination of the FixFlags enumeration values.
Updated to support the Microsoft .NET Framework 1.1 Final Beta (1.1.4322).
Added a new document that covers the main features of log4net. See the features document for more information.
The Hierarchy is now disabled until it has been configured. All messages logged to the Hierarchy before it has been configured will be ignored without an error message being written to the console.
If you are configuring log4net programmatically (i.e. not using one of the built-in configurators) you must set the ILoggerRepository.Configured property to true once you have configured the repository.
The no appenders defined for a logger message will no longer be displayed on the console by default. This message will only be displayed if internal debugging is enabled.
New examples in VisualBasic.NET, JScript and Managed C++. TODO Link to document about examples.
Code fixes. Documentation and manual updates. See the ChangeLog for more information.
See the Example Appender Configuration document for more information.
log4net 1.2.0 beta 6 adds support for the the following frameworks:
| Framework | Website |
|---|---|
| Microsoft .NET Framework 1.1 Final Beta (1.1.4322) | http://msdn.microsoft.com/net |
| Microsoft .NET Compact Framework 1.0 (1.0.5000) | http://msdn.microsoft.com/vstudio/device/compactfx.asp |
| Mono 0.23 | http://www.go-mono.org |
| Microsoft Shared Source CLI 1.0 | http://msdn.microsoft.com/library/en-us/dndotnet/html/mssharsourcecli.asp |
Not all frameworks are created equal and some features have been excluded from some of the builds. See the Framework Support document for more information.
The new build system allows log4net to be built for all supported frameworks and in all build configurations in one go.
The source code & distribution layout has been updated to support the new build environment and multiple target frameworks.
Updated default behavior of DefaultRepositorySelector. Assemblies are now by default placed into the default domain. To specify another domain, the DomainAttribute must be used. This is the opposite behavior to what was previously available. If you were previously specifying the DomainAttribute.UseDefaultDomain property then you should remove it, and if the default behavior is now sufficient, you do not need to specify the DomainAttribute at all.
Updated config file parser to use the element name as the property to set. Also removed <object> tag, the type attribute can now be specified on the property element directly.
For example:
<appender>
<param name="Evaluator">
<object type="log4net.spi.LevelEvaluator">
<constructor>
<param type="log4net.spi.Level" value="DEBUG"/>
</constructor>
</object>
</param>
</appender>becomes:
<appender>
<evaluator type="log4net.spi.LevelEvaluator">
<threshold value="DEBUG"/>
</evaluator>
</appender>The EventLogAppender now supports setting the event ID in the event log, this is taken from the EventID property from the per event Properties map on the LoggingEvent.
This allows the logging API to be wrapped or adapted for specific purposes. Two extension samples are included in the distribution:
| Extension | Description |
|---|---|
| log4net.Ext.Trace | Adds trace logging methods |
| log4net.Ext.EventID | Adds additional eventId parameter to all methods |
Appenders can add additional information to the events they are logging. The RemotingAppender and the SMTPAppender both add a 'hostname' property to the events. These properties can be accessed using the PatternLayout with the %P{name} syntax.
Specific appenders still require additional permissions to log correctly
This allows a parent assembly to take control of the logging domain for child assemblies.
The mapping from level name to level object is now repository specific, therefore each repository can have independent mappings.
This is controlled by the Hierarchy object and allows for better encapsulation.
This setting causes slow settings to be ignored. This significantly improves the performance of the buffered appenders.
The log4net.Repository.Hierarchy namespace now contains all the code that is specific to the Hierarchy implementation.
The Hierarchy specific data schema and implementation could be has now been moved to the log4net.Repository.Hierarchy namespace. The bootstrap code for these configurators remains in the log4net.Config namespace.
The instance methods from Category have moved to the Logger class. The static methods from Category have moved to the LogManager class. The Category class still exists but for backward compatibility only. Changed interface ICategoryFactory to ILoggerFactory and the implementation class DefaultCategoryFactory to DefaultLoggerFactory.
The Priority class has been replaced by the Level class. The Priority class still exists for backward compatibility only. The Level class implements a static pool of Level objects. The Level class is sealed and serializable.
The Hierarchy class implements the ILoggerRepository interface. This interface is used by the LogManager class and therefore allows different implementations of ILoggerRepository to be used.
All the NUnit tests can be run using a single TestSuite: NUnitGUI log4net.LogManager+AllTests,log4net.dll.
The LoggingEvent class is serializable. All local state is captured before serialization occurs. This now allows LoggingEvent objects to be serialized between applications or machines.
Delivers LoggingEvents to a remote interface. This can be used to collect distributed logging into a single log file. There is an example remoting sink that receives the logging events, see examples\net\remoting\RemotingServer for details.
The IObjectRenderer interface method DoRender now takes a RendererMap argument. This allows the renderer to use the appropriate renderer from the RendererMap to render any nested objects.
The DefaultRenderer now has support for rendering exceptions to a string. This includes nested exceptions. The RendererMap is now used to render exceptions in the LoggingEvent. This allows the rendering of specific exceptions to be enhanced by specific renderers.
This interface is used by SMTPAppender and RemotingAppender to determine if a LoggingEvent meets a set of user defined criteria. These appenders use the interface to determine whether or not to deliver the current buffer of events to their listener. The interface is implemented by the LevelEvaluator class, which triggers above a set level.
The MDCFilter, NDCFilter and StringMatchFilter can now be configured to use regex matches in addition to substring matches. Set the RegexToMatch property to use this feature.
emits an XML element for each LoggingEvent. This allows logging events to be stored and manipulated as XML. The DTD for the XML emitted is in the log4net-events.dtd
As the Category and Priority classes have been replaced by the Logger and Level classes. The DOMConfigurator has been updated to allow the <logger> and <level> elements to be used in place of the <category> and <priority> elements. The old elements are still accepted for backward compatibility.
Changed DisableXXX() methods on Hierarchy to a Threshold property.
The LogManager supports multiple logging domains. The LogManager uses an instance of the IRepositorySelector class to map from domains to ILoggerRepository instances. The default implementation is to have a separate ILoggerRepository for each domain. When a call is made to the static methods on LogManager the domain can be specified (as a string) or the domain can be inferred automatically from the calling assembly. The default behavior is for each assembly loaded into the process to have its own domain and ILoggerRepository. These can each be configured separately. This allows standalone assemblies to use log4net without conflicting with other modules in the process. The domain for the assembly is configured using metadata attributes defined on the assembly.