diff --git a/doc/BUILDING.md b/doc/BUILDING.md
index aeff9f6b..c666324e 100644
--- a/doc/BUILDING.md
+++ b/doc/BUILDING.md
@@ -1,9 +1,8 @@
## Building log4net
-Log4net provides support for a wide array of targets, including
-- older .net 2 and 3.5 (including client profiles)
-- more modern net40/net45
-- netstandard1.3/2.0
+Log4net provides support for the following targets
+- net462
+- netstandard2.0
As such, it does require a relatively full .net environment on Windows to build.
@@ -14,20 +13,6 @@ Options:
- include desktop targets at least
- include dotnet core targets or download and install
the latest dotnet sdk (you will need at least v2.1)
- - note that build is possible with VS2022 build tools, but I had to
- install VS2019 build tools _as well_ to get msbuild to recognise
- the legacy net35-profile target
- - Ensure you have .NET Framework 3.5 SP1 installed
- - on Win10+, this can only be installed via Add/Remove Windows Components
- - on other platforms, see https://dotnet.microsoft.com/download/dotnet-framework/net35-sp1
- - Building against .net 2/3.5, especially Client Profile, is not supported on Mono
- - Log4Net supports some older, out-of-support .net SDKs, particularly
- dotnet core 1.1 and .net framework client profiles for 3.5 and 4.0.
- There are helper powershell scripts in the root of this
- repository to assist with obtaining and installing these
- SDKs from Microsoft servers. Please see:
- - [install-dotnet-core-sdk-1.1.ps1](install-dotnet-core-sdk-1.1.ps1)
- - [install-net-framework-sdk-3.5.ps1](install-net-framework-sdk-3.5.ps1)
- Binaries can be built with a Visual Studio or Rider installation
- Binaries, packages and a release zip can be built via commandline
- Ensure that you have a reasonably modern NodeJS installed (at least version 8+)
diff --git a/doc/CONTRIBUTING.md b/doc/CONTRIBUTING.md
index 517def0c..97c74d67 100644
--- a/doc/CONTRIBUTING.md
+++ b/doc/CONTRIBUTING.md
@@ -8,7 +8,6 @@ follow so that we can have a chance of keeping on top of things.
Getting Started
---------------
-+ Make sure you have a [JIRA account](https://issues.apache.org/jira/).
+ Make sure you have a [GitHub account](https://github.com/signup/free).
+ If you're planning to implement a new feature it makes sense to discuss your changes on the [dev list](https://logging.apache.org/log4net/mail-lists.html) first. This way you can make sure you're not wasting your time on something that isn't considered to be in Apache log4net's scope.
+ Submit a ticket for your issue, assuming one does not already exist.
@@ -24,14 +23,14 @@ Making Changes
+ Respect the original code style:
+ Create minimal diffs - disable on save actions like reformat source code or organize imports. If you feel the source code should be reformatted create a separate PR for this change.
+ Check for unnecessary whitespace with git diff --check before committing.
-+ Make sure your commit messages are in the proper format. Your commit message should contain the key of the JIRA issue.
++ Make sure your commit messages are in the proper format. Your commit message should contain the key of the github issue.
+ Make sure you have added the necessary tests for your changes.
-+ Run all the tests with `nant` inside the `tests` directory to assure nothing else was accidentally broken.
++ Run all the tests with `npm test` to assure nothing else was accidentally broken.
Making Trivial Changes
----------------------
-For changes of a trivial nature to comments and documentation, it is not always necessary to create a new ticket in JIRA.
+For changes of a trivial nature to comments and documentation, it is not always necessary to create a new ticket in github.
In this case, it is appropriate to start the first line of a commit with '(doc)' instead of a ticket number.
Submitting Changes
@@ -40,12 +39,10 @@ Submitting Changes
+ Sign the [Contributor License Agreement][cla] if you haven't already.
+ Push your changes to a topic branch in your fork of the repository.
+ Submit a pull request to the repository in the apache organization.
-+ Update your JIRA ticket and include a link to the pull request in the ticket.
Additional Resources
--------------------
-+ [Apache log4net JIRA project page](https://issues.apache.org/jira/browse/LOG4NET)
+ [Contributor License Agreement][cla]
+ [General GitHub documentation](https://help.github.com/)
+ [GitHub pull request documentation](https://help.github.com/send-pull-requests/)
diff --git a/src/site/xdoc/release/building.xml b/src/site/xdoc/release/building.xml
index 9a9644d6..cf978610 100644
--- a/src/site/xdoc/release/building.xml
+++ b/src/site/xdoc/release/building.xml
@@ -17,107 +17,57 @@ limitations under the License.
-->
-
- Nicko Cadell
- Apache log4net: Building log4net
-
+
+ Nicko Cadell
+ Apache log4net: Building log4net
+
-
+
-
-
-
- The log4net release builds are built using NAnt. Log4net can also be built
- using Visual Studio .NET 2008 or 2010.
-
-
-
-
- Visual Studio .NET 2008 and 2010 are supported build platforms for log4net.
-
+
+
+
+ The log4net release builds are built using zarro. Log4net can also be built
+ using Visual Studio.
+
-
-
- The log4net distribution includes a solution and project file
- for Visual Studio .NET 2008. Open the log4net.vs2008.sln
- from the src directory in the distribution.
-
-
- The log4net project requires only the following references:
-
-
-
System
-
System.Configuration
-
System.Data
-
System.Web
-
System.XML
-
-
+
+
+ Visual Studio 2019 and 2022 are supported build platforms for log4net.
+
-
-
- The log4net distribution includes a solution and project file
- for Visual Studio .NET 2010. Open the log4net.vs2010.sln
- from the src directory in the distribution.
-
-
- The log4net project requires only the following references:
-
-
-
System
-
System.Configuration
-
System.Data
-
System.Web
-
System.XML
-
-
-
-
-
-
- The log4net distribution is built using the NAnt tool.
- A recent NAnt version 0.91 alpha2 is required to build log4net, this is
- available from nant.sourceforge.net.
-
-
- To support building log4net for the SSCLI framework the NAnt configuration
- files need to be updated to specify the SSCLI framework directory.
-
-
- To build log4net from the command line, change directory to the root of the
- log4net distribution, ensure that the nant executable is in the
- PATH, and then run the following command:
-
-
-nant -buildfile:log4net.build compile-all
-
- This command will build log4net for all the supported frameworks
- that are available on the current machine. To list all the build
- targets that are available run the following command:
-
-
-nant -buildfile:log4net.build -projecthelp
-
- Under windows the build.cmd can be used
- to script the nant build. This can be called from a different
- directory and will locate the correct log4net.build file to use.
- For example:
-
-
-build.cmd compile-all
-
+
+
+ The log4net distribution includes a solution and project file
+ for Visual Studio. Open the log4net.sln
+ from the src directory in the distribution.
+
+
+ The log4net project requires only the following references:
+
+
+
System
+
System.Configuration
+
System.Data
+
System.Web
+
System.XML
+
+
+
-
-
- Sandcastle
- Helpfile Builder is used to build the log4net SDK
- documentation. Running it is currently not
- integrated with the NAnt build process, you'll
- have to open and run log4net.shfbproj
- with SHFB manually.
-
-
+
+
+
+ Sandcastle
+ Helpfile Builder
+ is used to build the log4net SDK
+ documentation. Running it is currently not
+ integrated with the NAnt build process, you'll
+ have to open and run log4net.shfbproj
+ with SHFB manually.
+
- The following examples are only available in the log4net source download, not
- on-line. To obtain the examples download the log4net source release.
-
-
-
-
-
-
-
- A single example can be build by running nant from
- the example directory.
-
-
- For example running nant in the
- examples\net\1.0\Tutorials\ConsoleApp\cs directory
- will build the C# version of the Microsoft® .NET 1.0 ConsoleApp example.
-
-
- nant can be run in any directory containing a
- nant.build file. The typical behavior of the build file
- is to build all projects under the current directory.
-
-
- For example running nant in the
- examples\net\1.1 directory
- will build all the examples for the .NET 1.1 platform.
-
-
-
-
-
- To build all the examples either run nant in the
- examples directory or you can specify the
- compile-examples target to the main log4net nant build.
-
-
-
-
-
- There are Visual Studio .NET 2002 project files for the .NET 1.0 framework.
- The solution files for C# and VB are in the examples\net\1.0
- folder.
-
-
- For the Managed C++ project there is a Visual Studio .NET 2003 project file
- in the examples\net\1.1 folder.
-
-
-
-
-
-
-
-
- ConsoleApp shows how to write a simple console application that initializes
- logging and logs various events.
-
-
- This example is available for the following platforms and languages. If a version
- is not available for your chosen platform and language combination then select the
- nearest platform for the appropriate language.
-
-
-
- MONO 1.0:
- C#
-
-
- .NET 1.0:
- C#,
- VB
-
-
- .NET 1.1:
- C++,
- JScript.NET
-
-
- .NET Compact Framework 1.0:
- C#,
- VB
-
-
- SSCLI 1.0:
- JScript.NET
-
-
-
- To run this example execute ConsoleApp.exe from the build output directory.
-
-
-
-
-
- ConsoleApp shows how to write a simple ASP.NET web application that initializes
- logging and logs various events.
-
-
- This example is available for the following platforms and languages. If a version
- is not available for your chosen platform and language combination then select the
- nearest platform for the appropriate language.
-
-
-
- .NET 1.0:
- C#,
- VB
-
-
-
- To run this example you need to have an ASP.NET container application to
- host the web application, for example IIS. In IIS create a new virtual
- directory pointing to the WebApp src directory. Configure IIS to recognize
- this virtual directory as an application. Open up a web browser, navigate to
- the virtual directory and to the WebForm1.aspx page within it.
-
-
-
-
-
- The RemotingClient application is a simple console application that configures
- log4net with the RemotingAppender. This appender will attempt to deliver the
- logging events to a remoting listener. This example should be run in conjunction
- with the RemotingServer.
-
-
- This example is available for the following platforms and languages. If a version
- is not available for your chosen platform and language combination then select the
- nearest platform for the appropriate language.
-
-
-
- .NET 1.0:
- C#
-
-
-
- To run this example execute RemotingClient.exe from the build output directory.
-
-
-
-
-
- The RemotingServer application is a simple console application that listens for
- logging events from a remote RemotingAppender and then logs them through the
- local log4net instance. This example should be run in conjunction
- with the RemotingClient.
-
-
- This example is available for the following platforms and languages. If a version
- is not available for your chosen platform and language combination then select the
- nearest platform for the appropriate language.
-
-
-
- .NET 1.0:
- C#
-
-
-
- To run this example execute RemotingServer.exe from the build output directory.
- While this process is running execute the RemotingClient.exe program on
- the same machine. The logging events from the client are transferred to the server.
-
-
-
-
-
- The SimpleModule is a class library that is intended to be used as part of
- the SimpleApp example,
- This class library uses the log4net.Config.Repository
- attribute to create a separate configuration space from other assemblies.
-
-
- This example is available for the following platforms and languages. If a version
- is not available for your chosen platform and language combination then select the
- nearest platform for the appropriate language.
-
-
-
- MONO 1.0:
- C#
-
-
- .NET 1.0:
- C#,
- VB
-
-
- .NET 1.1:
- JScript.NET
-
-
- SSCLI 1.0:
- C#
-
-
-
- This library is intended to be used as part of the SimpleApp example.
-
-
-
-
-
- The SharedModule is a class library that is intended to be used as part of
- the SimpleApp example,
- This class library uses log4net but does not attempt to configure logging.
-
-
- This example is available for the following platforms and languages. If a version
- is not available for your chosen platform and language combination then select the
- nearest platform for the appropriate language.
-
-
-
- MONO 1.0:
- C#
-
-
- .NET 1.0:
- C#,
- VB
-
-
- .NET 1.1:
- JScript.NET
-
-
- SSCLI 1.0:
- C#
-
-
-
- This library is intended to be used as part of the SimpleApp example.
-
-
-
-
-
- The SimpleApp example uses the SimpleModule and SharedModule to demonstrate
- the ways in which multiple assemblies within the same process may be
- separately configured.
-
-
- This example is available for the following platforms and languages. If a version
- is not available for your chosen platform and language combination then select the
- nearest platform for the appropriate language.
-
-
-
- MONO 1.0:
- C#
-
-
- .NET 1.0:
- C#,
- VB
-
-
- .NET 1.1:
- JScript.NET
-
-
- SSCLI 1.0:
- C#
-
-
-
- To run this example execute SimpleApp.exe from the build output directory.
-
-
-
-
-
- The EventIDLogApp example demonstrates using the log4net.Ext.EventID extension.
- The extension needs to be built separately from the
- extensions\net\1.0\log4net.Ext.EventID directory.
-
-
- This example is available for the following platforms and languages. If a version
- is not available for your chosen platform and language combination then select the
- nearest platform for the appropriate language.
-
-
-
- .NET 1.0:
- C#
-
-
-
- To run this example execute EventIDLogApp.exe from the build output directory.
-
-
-
-
-
- The TraceLogApp example demonstrates using the log4net.Ext.Trace extension.
- The extension needs to be built separately from the
- extensions\net\1.0\log4net.Ext.Trace directory.
-
-
- This example is available for the following platforms and languages. If a version
- is not available for your chosen platform and language combination then select the
- nearest platform for the appropriate language.
-
-
-
- .NET 1.0:
- C#
-
-
-
- To run this example execute TraceLogApp.exe from the build output directory.
-
-
-
-
-
- This project includes the following example appenders.
-
-
-
- AsyncAppender
-
-
- FastDbAppender
-
-
- FireEventAppender
-
-
- MessageBoxAppender
-
-
- MessageObjectExpanderAppender
-
-
- MsmqAppender
-
-
- PatternFileAppender
-
-
- SimpleSmtpAppender
-
-
-
- This example is available for the following platforms and languages. If a version
- is not available for your chosen platform and language combination then select the
- nearest platform for the appropriate language.
-
-
-
- .NET 1.0:
- C#
-
-
-
- To run this example execute SampleAppendersApp.exe from the build output directory.
-
-
-
-
-
- This project includes the following example layouts.
-
-
-
- ForwardingLayout
-
-
- LineWrappingLayout
-
-
-
- This example is available for the following platforms and languages. If a version
- is not available for your chosen platform and language combination then select the
- nearest platform for the appropriate language.
-
-
-
- .NET 1.0:
- C#
-
-
-
- To run this example execute SampleLayoutsApp.exe from the build output directory.
-
-
-
-
-
- The NotLogging example benchmarks the performance of log4net logging statements in
- user code in various scenarios including when logging is disabled.
-
-
- This example is available for the following platforms and languages. If a version
- is not available for your chosen platform and language combination then select the
- nearest platform for the appropriate language.
-
-
-
- MONO 1.0:
- C#
-
-
- .NET 1.0:
- C#,
- VB
-
-
-
-
-
-
-
-
- The WmiAppender sample shows an example appender that fires events through
- Windows Management Instrumentation.
-
-
- This example is available for the following platforms and languages. If a version
- is not available for your chosen platform and language combination then select the
- nearest platform for the appropriate language.
-
-
-
- .NET 1.0:
- C#
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+ The following examples are only available in the log4net source download, not
+ on-line. To obtain the examples download the log4net source release.
+
+
+
+
+
+
+
+
+ There are Visual Studio project files
+ The solution files for C# and VB are in the examples\net\2.0
+ folder.
+
+
+
+
+
+
+
+
+ ConsoleApp shows how to write a simple console application that initializes
+ logging and logs various events.
+
+
+ This example is available for the following platforms and languages. If a version
+ is not available for your chosen platform and language combination then select the
+ nearest platform for the appropriate language.
+
+
+ To run this example execute ConsoleApp.exe from the build output directory.
+
+
+
+
+
+ ConsoleApp shows how to write a simple ASP.NET web application that initializes
+ logging and logs various events.
+
+
+ This example is available for the following platforms and languages. If a version
+ is not available for your chosen platform and language combination then select the
+ nearest platform for the appropriate language.
+
+
+ To run this example you need to have an ASP.NET container application to
+ host the web application, for example IIS. In IIS create a new virtual
+ directory pointing to the WebApp src directory. Configure IIS to recognize
+ this virtual directory as an application. Open up a web browser, navigate to
+ the virtual directory and to the WebForm1.aspx page within it.
+
+
+
+
+
+ The RemotingClient application is a simple console application that configures
+ log4net with the RemotingAppender. This appender will attempt to deliver the
+ logging events to a remoting listener. This example should be run in conjunction
+ with the RemotingServer.
+
+
+ This example is available for the following platforms and languages. If a version
+ is not available for your chosen platform and language combination then select the
+ nearest platform for the appropriate language.
+
+
+ To run this example execute RemotingClient.exe from the build output directory.
+
+
+
+
+
+ The RemotingServer application is a simple console application that listens for
+ logging events from a remote RemotingAppender and then logs them through the
+ local log4net instance. This example should be run in conjunction
+ with the RemotingClient.
+
+
+ This example is available for the following platforms and languages. If a version
+ is not available for your chosen platform and language combination then select the
+ nearest platform for the appropriate language.
+
+
+ To run this example execute RemotingServer.exe from the build output directory.
+ While this process is running execute the RemotingClient.exe program on
+ the same machine. The logging events from the client are transferred to the server.
+
+
+
+
+
+ The SimpleModule is a class library that is intended to be used as part of
+ the SimpleApp example,
+ This class library uses the log4net.Config.Repository
+ attribute to create a separate configuration space from other assemblies.
+
+
+ This example is available for the following platforms and languages. If a version
+ is not available for your chosen platform and language combination then select the
+ nearest platform for the appropriate language.
+
+
+ This library is intended to be used as part of the SimpleApp example.
+
+
+
+
+
+ The SharedModule is a class library that is intended to be used as part of
+ the SimpleApp example,
+ This class library uses log4net but does not attempt to configure logging.
+
+
+ This example is available for the following platforms and languages. If a version
+ is not available for your chosen platform and language combination then select the
+ nearest platform for the appropriate language.
+
+
+ This library is intended to be used as part of the SimpleApp example.
+
-
+
+
+
+ The SimpleApp example uses the SimpleModule and SharedModule to demonstrate
+ the ways in which multiple assemblies within the same process may be
+ separately configured.
+
+
+ This example is available for the following platforms and languages. If a version
+ is not available for your chosen platform and language combination then select the
+ nearest platform for the appropriate language.
+
+
+ To run this example execute SimpleApp.exe from the build output directory.
+
+
+
+
+
+ The EventIDLogApp example demonstrates using the log4net.Ext.EventID extension.
+ The extension needs to be built separately from the
+ extensions\net\1.0\log4net.Ext.EventID directory.
+
+
+ This example is available for the following platforms and languages. If a version
+ is not available for your chosen platform and language combination then select the
+ nearest platform for the appropriate language.
+
+
+ To run this example execute EventIDLogApp.exe from the build output directory.
+
+
+
+
+
+ The TraceLogApp example demonstrates using the log4net.Ext.Trace extension.
+ The extension needs to be built separately from the
+ extensions\net\1.0\log4net.Ext.Trace directory.
+
+
+ This example is available for the following platforms and languages. If a version
+ is not available for your chosen platform and language combination then select the
+ nearest platform for the appropriate language.
+
+
+ To run this example execute TraceLogApp.exe from the build output directory.
+
+
+
+
+
+ This project includes the following example appenders.
+
+
+
+ AsyncAppender
+
+
+ FastDbAppender
+
+
+ FireEventAppender
+
+
+ MessageBoxAppender
+
+
+ MessageObjectExpanderAppender
+
+
+ MsmqAppender
+
+
+ PatternFileAppender
+
+
+ SimpleSmtpAppender
+
+
+
+ This example is available for the following platforms and languages. If a version
+ is not available for your chosen platform and language combination then select the
+ nearest platform for the appropriate language.
+
+
+ To run this example execute SampleAppendersApp.exe from the build output directory.
+
+
+
+
+
+ This project includes the following example layouts.
+
+
+
+ ForwardingLayout
+
+
+ LineWrappingLayout
+
+
+
+ This example is available for the following platforms and languages. If a version
+ is not available for your chosen platform and language combination then select the
+ nearest platform for the appropriate language.
+
+
+ To run this example execute SampleLayoutsApp.exe from the build output directory.
+
+
+
+
+
+ The NotLogging example benchmarks the performance of log4net logging statements in
+ user code in various scenarios including when logging is disabled.
+
+
+ This example is available for the following platforms and languages. If a version
+ is not available for your chosen platform and language combination then select the
+ nearest platform for the appropriate language.
+
+
+
+
+
+
+
+ The WmiAppender sample shows an example appender that fires events through
+ Windows Management Instrumentation.
+
+
+ This example is available for the following platforms and languages. If a version
+ is not available for your chosen platform and language combination then select the
+ nearest platform for the appropriate language.
+
- log4net is a tool to help the programmer output log statements to a variety of
- output targets.
-
-
- In case of problems with an application, it is helpful to enable logging so
- that the problem can be located. With log4net it is possible to enable logging at
- runtime without modifying the application binary. The log4net package is designed
- so that log statements can remain in production code without incurring a
- high performance cost. It follows that the speed of logging (or rather not
- logging) is crucial.
-
-
- At the same time, log output can be so voluminous that it quickly becomes
- overwhelming. One of the distinctive features of log4net (and common to all of
- the log4x libraries) is the notion of hierarchical
- loggers. Using these loggers it is possible to selectively control
- which log statements are output at arbitrary granularity.
-
-
- log4net is designed with two distinct goals in mind: speed and flexibility. There
- is a tight balance between these two requirements.
-
- No. log4net is not reliable. It is a best-effort and fail-stop logging system.
-
-
- By fail-stop, we mean that log4net will not throw unexpected exceptions at
- run-time potentially causing your application to crash. If for any reason, log4net
- throws an uncaught exception (except for ArgumentException and
- ArgumentNullException which may be thrown), please send an email
- to the
- log4net-user@logging.apache.org mailing list. Uncaught exceptions
- are handled as serious bugs requiring immediate attention.
-
-
- Moreover, log4net will not revert to System.Console.Out
- or System.Console.Error when its designated
- output stream is not opened, is not writable or becomes full. This avoids
- corrupting an otherwise working program by flooding the user's terminal because
- logging fails. However, log4net will output a single message to
- System.Console.Error and System.Diagnostics.Trace
- indicating that logging can not be performed.
-
- log4net runs on many different frameworks and each framework has its own requirements.
- As a rule of thumb you will need an ECMA-335 compliant CLI runtime, for example,
- the Microsoft® .NET runtime 1.0 (1.0.3705) or 1.1 (1.1.4322).
-
-
- 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 log output can be customized in many ways. Moreover, one can completely
- override the output format by implementing one's own ILayout
-
-
- Here is an example output using PatternLayout with the conversion
- pattern %timestamp [%thread] %-5level %logger{2} %ndc - %message%newline
-
-
+
+ Note: the .NET Compact Framework 1.0 does not support System.Reflection.MethodBase.GetCurrentMethod().
+
+
+
+ Note: the two forms are only equivalent
+ if Foo is not a
+ generic class. For a generic class Foo<T> the variant
- using typeof generates
- a different logger for each different type
- parameter T while the
- variant using reflection generates the same
- logger for all Ts.
-
- incurs the cost of constructing the message parameter, that is converting both
- integer i and entry[i] to
- a string, and concatenating intermediate strings. This, regardless of whether
- the message will be logged or not.
-
-
- If you are worried about speed, then write
-
- typeof generates
+ a different logger for each different type
+ parameter T while the
+ variant using reflection generates the same
+ logger for all Ts.
+
+ incurs the cost of constructing the message parameter, that is converting both
+ integer i and entry[i] to
+ a string, and concatenating intermediate strings. This, regardless of whether
+ the message will be logged or not.
+
+
+ If you are worried about speed, then write
+
+
+
-
- This way you will not incur the cost of parameter construction if debugging is
- disabled for logger log. On the other hand, if the logger is
- debug enabled, you will incur the cost of evaluating whether the logger is
- enabled or not, twice: once in IsDebugEnabled and once in Debug.
- This is an insignificant overhead since evaluating a logger takes less than
- 1% of the time it takes to actually log a statement.
-
- So you don't think that the previous FAQ is really the fastest way
- of not logging? Well there is a faster way but it does have some
- drawbacks. Starting from:
-
-
+
+
+ This way you will not incur the cost of parameter construction if debugging is
+ disabled for logger log. On the other hand, if the logger is
+ debug enabled, you will incur the cost of evaluating whether the logger is
+ enabled or not, twice: once in IsDebugEnabled and once in Debug.
+ This is an insignificant overhead since evaluating a logger takes less than
+ 1% of the time it takes to actually log a statement.
+
+ So you don't think that the previous FAQ is really the fastest way
+ of not logging? Well there is a faster way but it does have some
+ drawbacks. Starting from:
+
+
+
-
- It is possible to further eliminate the calls to IsDebugEnabled
- so that the call is only made once per logger. If you are using one logger
- for each class then you can store the enabled state for the logger in a static
- variable in the class and then test against this variable:
-
-
+
+
+ It is possible to further eliminate the calls to IsDebugEnabled
+ so that the call is only made once per logger. If you are using one logger
+ for each class then you can store the enabled state for the logger in a static
+ variable in the class and then test against this variable:
+
+
+
-
- So why exactly is this faster? Well to start with the IsDebugEnabled
- is not called for each log statement, it is called once per logger. Furthermore as the
- isDebugEnabled variable is private static readonly
- the JIT compiler can at run-time optimize out the if test altogether.
- This means that at runtime the JIT compiler won't even compile the logging statements into native code, i.e.
- all the logging just disappears.
-
-
- So what is the downside to using this? Well one of the clever features of log4net is that
- you can change the logging configuration while your program is running. If you need to
- investigate an issue in your application, you don't have to stop the application, setup the
- logging and restart the application, you can change the logging configuration and the
- log4net will reload it (see XmlConfigurator.ConfigureAndWatch APIs for more
- information). However if the JIT has compiled out all of the logging statements
- then they are gone and you can't get them back by reloading the configuration file. Effectively
- this means that the logging configuration can only be set when the application loads and
- it cannot be changed at runtime. It is up to you to decide if you need ultimate speed or need
- to be able to reload the logging configuration while the application is running.
-
- Many developers are confronted with the problem of distinguishing the log
- output originating from the same class but different client requests. They come
- up with ingenious mechanisms to fan out the log output to different files. In
- most cases, this is not the right approach.
-
-
- It is simpler to use a context property or stack (ThreadContext).
- Typically, one would ThreadContext.Properties["ID"] = "XXX"
- client specific information, such as the client's hostname, ID or any other
- distinguishing information when starting to handle the client's request.
- Thereafter, log output will automatically include the context data
- so that you can distinguish logs from different client requests even if they
- are output to the same file.
-
-
- See the ThreadContext and the PatternLayout classes for more
- information.
-
- Before you even start trying any of the
- alternatives provided, ask yourself whether you
- really need to have multiple processes log to the
- same file, then don't do it ;-).
-
-
-
- FileAppender offers pluggable locking models for
- this usecase but all existing implementations have
- issues and drawbacks.
-
-
-
- By default the
+
+
+ So why exactly is this faster? Well to start with the IsDebugEnabled
+ is not called for each log statement, it is called once per logger. Furthermore as the
+ isDebugEnabled variable is private static readonly
+ the JIT compiler can at run-time optimize out the if test altogether.
+ This means that at runtime the JIT compiler won't even compile the logging statements into native code, i.e.
+ all the logging just disappears.
+
+
+ So what is the downside to using this? Well one of the clever features of log4net is that
+ you can change the logging configuration while your program is running. If you need to
+ investigate an issue in your application, you don't have to stop the application, setup the
+ logging and restart the application, you can change the logging configuration and the
+ log4net will reload it (see XmlConfigurator.ConfigureAndWatch APIs for more
+ information). However if the JIT has compiled out all of the logging statements
+ then they are gone and you can't get them back by reloading the configuration file. Effectively
+ this means that the logging configuration can only be set when the application loads and
+ it cannot be changed at runtime. It is up to you to decide if you need ultimate speed or need
+ to be able to reload the logging configuration while the application is running.
+
+ Many developers are confronted with the problem of distinguishing the log
+ output originating from the same class but different client requests. They come
+ up with ingenious mechanisms to fan out the log output to different files. In
+ most cases, this is not the right approach.
+
+
+ It is simpler to use a context property or stack (ThreadContext).
+ Typically, one would ThreadContext.Properties["ID"] = "XXX"
+ client specific information, such as the client's hostname, ID or any other
+ distinguishing information when starting to handle the client's request.
+ Thereafter, log output will automatically include the context data
+ so that you can distinguish logs from different client requests even if they
+ are output to the same file.
+
+
+ See the ThreadContext and the PatternLayout classes for more
+ information.
+
+ Before you even start trying any of the
+ alternatives provided, ask yourself whether you
+ really need to have multiple processes log to the
+ same file, then don't do it ;-).
+
+
+
+ FileAppender offers pluggable locking models for
+ this usecase but all existing implementations have
+ issues and drawbacks.
+
+
+
+ By default the FileAppender holds an
- exclusive write lock on the log file while it
- is logging. This prevents other processes from
- writing to the file. This model is known to
- break down with (at least on some versions of)
- Mono on Linux and log files may get corrupted
- as soon as another process tries to access the
- log file.
-
-
-
- MinimalLock only
- acquires the write lock while a log is being
- written. This allows multiple processes to
- interleave writes to the same file, albeit with
- a considerable loss in performance.
-
-
- InterProcessLock
- doesn't lock the file at all but synchronizes
- using a system wide Mutex. This will only work
- if all processes cooperate (and use the same
- locking model). The acquisition and release of a
- Mutex for every log entry to be written will
- result in a loss of performance, but the Mutex
- is preferable to the use of MinimalLock.
-
-
- If you use RollingFileAppender things
- become even worse as several process may try to
- start rolling the log file concurrently.
+
+
+ MinimalLock only
+ acquires the write lock while a log is being
+ written. This allows multiple processes to
+ interleave writes to the same file, albeit with
+ a considerable loss in performance.
+
+
+ InterProcessLock
+ doesn't lock the file at all but synchronizes
+ using a system wide Mutex. This will only work
+ if all processes cooperate (and use the same
+ locking model). The acquisition and release of a
+ Mutex for every log entry to be written will
+ result in a loss of performance, but the Mutex
+ is preferable to the use of MinimalLock.
+
+
+ If you use RollingFileAppender things
+ become even worse as several process may try to
+ start rolling the log file concurrently. RollingFileAppender
- completely ignores the locking model when
- rolling files, rolling files is simply not
- compatible with this scenario.
-
-
- A better alternative is to have your processes
- log to RemotingAppenders. Using
- the RemoteLoggingServerPlugin
- (or IRemoteLoggingSink) a
- process can receive all the events and log
- them to a single log file. One of the
- examples shows how to use the
+
+ A better alternative is to have your processes
+ log to RemotingAppenders. Using
+ the RemoteLoggingServerPlugin
+ (or IRemoteLoggingSink) a
+ process can receive all the events and log
+ them to a single log file. One of the
+ examples shows how to use the RemoteLoggingServerPlugin.
-
- The timestamp is created when the logging event is created. That is so say,
- when the Debug, Info,
- Warn, Error
- or Fatal method is invoked. This is unaffected by the time at
- which they may arrive at a remote server. Since the timestamps are
- transmitted in UTC format by the RemotingAppender,
- they all appear in the same time zone as
- the host creating the logfile. Since the clocks of various machines may not be
- synchronized, this may account for time interval inconsistencies between events
- generated on different hosts.
-
- The simple answer is as soon as possible. The long answer is more complex.
-
-
- If you are configuring log4net programmatically, i.e. by calling the
- XmlConfigurator.Configure method then you should do so
- before you begin logging and it is reasonable to do this very soon after application
- start.
-
-
- If you are configuring log4net by specifying assembly level attributes on
- your assembly then the configuration will be loaded once the first call to
- the LogManager.GetLogger is made. It is necessary
- that the first call to LogManager.GetLogger made
- during the process (or AppDomain) is made from the assembly that has the
- configuration attributes. Log4net will look only once and only on the first
- calling assembly for the configuration attributes.
-
- Yes. You can implement the log4net.Layout.ILayout
- interface to create you own customized log format, or you can extend the
- LayoutSkeleton class which provides a default
- implementation of the ILayout interface.
- Appenders can be parameterized to use the layout of your choice.
-
- Yes. You can implement the log4net.Appender.IAppender
- interface to create you own customized appender. We recommend that you extend the
- log4net.Appender.AppenderSkeleton class rather than
- starting from scratch. You should implement your custom code in a assembly
- separate from the log4net assembly. To get started it is worth looking at the
- source of the log4net.Appender.TraceAppender as an
- example of the minimum amount of code required to get an appender working.
-
-
- To configure log4net to use your custom appender you need to specify the
- assembly qualified name of the appender type in the config file. For
- example:
-
- ]]>
-
- The .NET runtime will try to locate the assembly called MyAssembly.
- How .NET locates assemblies is beyond the scope of this FAQ.
-
- There are 2 different ways to enable internal debugging in log4net.
- These are listed below. The preferred method is to specify
- the log4net.Internal.Debug option in the application's
- config file.
-
-
-
-
- Internal debugging can also be enabled by setting a value in the application's
- configuration file (not the log4net configuration file, unless the log4net config
- data is embedded in the application's config file). The log4net.Internal.Debug
- application setting must be set to the value true.
- For example:
-
- This setting is read immediately on startup an will cause all internal
- debugging messages to be emitted.
-
-
-
-
- To enable log4net's internal debug programmatically you need
- to set the log4net.Util.LogLog.InternalDebugging
- property to true. Obviously the sooner this
- is set the more debug will be produced.
-
-
-
-
- Internal debugging messages are written to the console and to the
- System.Diagnostics.Trace
- system. If the application does not have a console the messages logged
- there will be lost. Note that an application can redirect the console
- stream by setting the System.Console.Out. The
- Trace system will by default send the message to an attached debugger
- (where the messages will appear in the output window). If the process
- does not have a debugger attached then the messages are sent to the
- system debugger. A utility like DebugView from
- http://www.sysinternals.com
- may be used to capture these messages.
-
-
- As log4net internal debug messages are written to the System.Diagnostics.Trace
- system it is possible to redirect those messages to a local file. You can define
- a trace listener by adding the following to your application's .config file:
-
- To prevent silent failure of log4net as reported as LOG4NET-342,
- log4net supports a way to evaluate if it was configured and also to evaluate messages generated on startup since 1.2.11. To
- check if log4net was started and configured properly one can check the property
- log4net.Repository.ILoggerRepository.Configured and enumerate the configuration messages as follows:
-
- If you are not getting events delivered to the event log this usually indicates
- a permissions problem. Basically if the event log does not exist the EventLogAppender
- tries to create it, but you need local administrator permissions to create event logs
- (just to write into the right bit of the registry). You don't need administrator
- permissions to log to an existing event log, but it must exist. If you are using the
- event log from a web application or service using the event log can be a little tricky.
-
-
- A web application will run as the user account ASPNET. This account deliberately has
- few permissions to reduce the chances of someone hacking into the web server. While the
- account has permission to write to the event log it does not have permission to create
- event sources (registry create and write access), which are needed to write to the event log.
-
-
- There are a couple of solutions:
-
-
-
-
- Make the ASPNET user a member of the Administrators group. This will work because the
- user will then have the required permissions. This is not recommended
- for production use.
-
-
-
-
- As the event source only needs to be created once for the machine, create an installer
- and configure it to create the event source.
- The installer will need to be run as Administrator (don't they all). See
- System.Diagnostics.EventLogInstaller in the Microsoft .NET
- Framework SDK for an example of how to create a simple event log installer.
-
- The web application runs as a special user account on the web server
- called ASPNET. This account has restricted permissions to protect the
- web server from attacks. By default this account may not have permission
- to write to the file system. Make sure that the ASPNET account has
- permission to create and write to files in the directory chosen for
- logging.
-
- A windows service runs as a user account specified in the services
- control panel. This account may have restricted permissions, make
- sure that the account has permission to create and write to files
- in the directory chosen for logging.
-
-
- A windows service is launched by windows. The current directory in
- a service is set to the windows system directory (e.g.
- C:\Windows\System32). If you are loading
- the configuration file from the current directory then be aware
- that this path will not be the location of your assemblies.
- The best way to get the path to your assemblies is to use
- AppDomain.BaseDirectory.
- Note that the log4net internals never use the current directory.
-
- This problem has been reported by several people as issue
- LOG4NET-178.
- The issue seems to be caused by a broken LOG4NET configuration
- or a timing problem caused by an application shutdown event that
- floats in late after an application start event and thus LOG4NET
- stops logging immediately after it has been started.
-
-
- The first thing step to troubleshoot problems is enabling
- the log4net internal debugging features as described
- here
- and fix all errors that pop up. If the problem still persists,
- this comment
- suggests to move the LOG4NET configuration out of the
- web.config into a separate file
- like log4net.config. Finally,
- if both previous steps did not help and the problem still
- occurs, you can try to work around the event timing problem
- by invoking the configuration call from the class constructor as described in
- this comment.
-
- If you need to use ODBC to connect to your database then please note that the
- ADO.NET ODBC drivers are not included in the standard .NET framework redistributable.
- You can download the drivers from microsoft download at:
- ODBC .NET Data Provider.
-
- First make sure it really is a bug and not a
- usage error. When in doubt, ask on the log4net-user mailing
- list first.
-
-
- If you have identified a bug, please report it
- via our Issue
- Tracker. You may want to check it hasn't
- been reported before by searching the existing
- issues.
-
- If you use attributes to configure log4net then
- the order by which assemblies are loaded may
- determine whether you attributes are used or
- not. Assembly load order may be different in
- DEBUG and RELEASE mode.
-
-
-
- As stated in the
- manual the attribute will only be read for
- the first assembly that tries to use log4net.
- So it is important that you obtain your
- ILog instance as early as possible.
-
-
-
- For a command line application "as early as
- possible" probably is the class holding the
- Main method, for a Web-Application
- it would be your Global.asax class
- and for a Windows Service it would be the class
- deriving from ServiceBase.
-
- You may have overlooked initialization code for
- log4net in your application. log4net can be
- initialized explicitly by calling one of the
- configurators
- (e.g. BasicConfigurator or
- XmlConfigurator in the
- log4net.Config namespace, or
- implicitly by including the
- [XmlConfiguratorAttribute] in the
- assembly where log4net is first used.
-
-
-
- See the
- manual for more information. If you use
- attributes to configure log4net then the order
- by which assemblies are loaded may determine
- whether you attributes are used or not.
- Assembly load order may be different in DEBUG
- and RELEASE mode. See also log4net doesn't log when built
- in RELEASE mode.
-
+ The timestamp is created when the logging event is created. That is so say,
+ when the Debug, Info,
+ Warn, Error
+ or Fatal method is invoked. This is unaffected by the time at
+ which they may arrive at a remote server. Since the timestamps are
+ transmitted in UTC format by the RemotingAppender,
+ they all appear in the same time zone as
+ the host creating the logfile. Since the clocks of various machines may not be
+ synchronized, this may account for time interval inconsistencies between events
+ generated on different hosts.
+
+ The simple answer is as soon as possible. The long answer is more complex.
+
+
+ If you are configuring log4net programmatically, i.e. by calling the
+ XmlConfigurator.Configure method then you should do so
+ before you begin logging and it is reasonable to do this very soon after application
+ start.
+
+
+ If you are configuring log4net by specifying assembly level attributes on
+ your assembly then the configuration will be loaded once the first call to
+ the LogManager.GetLogger is made. It is necessary
+ that the first call to LogManager.GetLogger made
+ during the process (or AppDomain) is made from the assembly that has the
+ configuration attributes. Log4net will look only once and only on the first
+ calling assembly for the configuration attributes.
+
+ Yes. You can implement the log4net.Layout.ILayout
+ interface to create you own customized log format, or you can extend the
+ LayoutSkeleton class which provides a default
+ implementation of the ILayout interface.
+ Appenders can be parameterized to use the layout of your choice.
+
+ Yes. You can implement the log4net.Appender.IAppender
+ interface to create you own customized appender. We recommend that you extend the
+ log4net.Appender.AppenderSkeleton class rather than
+ starting from scratch. You should implement your custom code in a assembly
+ separate from the log4net assembly. To get started it is worth looking at the
+ source of the log4net.Appender.TraceAppender as an
+ example of the minimum amount of code required to get an appender working.
+
+
+ To configure log4net to use your custom appender you need to specify the
+ assembly qualified name of the appender type in the config file. For
+ example:
+
+
+ ]]>
+
+
+ The .NET runtime will try to locate the assembly called MyAssembly.
+ How .NET locates assemblies is beyond the scope of this FAQ.
+
+ There are 2 different ways to enable internal debugging in log4net.
+ These are listed below. The preferred method is to specify
+ the log4net.Internal.Debug option in the application's
+ config file.
+
+
+
+
+ Internal debugging can also be enabled by setting a value in the application's
+ configuration file (not the log4net configuration file, unless the log4net config
+ data is embedded in the application's config file). The log4net.Internal.Debug
+ application setting must be set to the value true.
+ For example:
+
+ This setting is read immediately on startup an will cause all internal
+ debugging messages to be emitted.
+
+
+
+
+ To enable log4net's internal debug programmatically you need
+ to set the log4net.Util.LogLog.InternalDebugging
+ property to true. Obviously the sooner this
+ is set the more debug will be produced.
+
+
+
+
+ Internal debugging messages are written to the console and to the
+ System.Diagnostics.Trace
+ system. If the application does not have a console the messages logged
+ there will be lost. Note that an application can redirect the console
+ stream by setting the System.Console.Out. The
+ Trace system will by default send the message to an attached debugger
+ (where the messages will appear in the output window). If the process
+ does not have a debugger attached then the messages are sent to the
+ system debugger. A utility like DebugView from
+ http://www.sysinternals.com
+ may be used to capture these messages.
+
+
+ As log4net internal debug messages are written to the System.Diagnostics.Trace
+ system it is possible to redirect those messages to a local file. You can define
+ a trace listener by adding the following to your application's .config file:
+
+ To prevent silent failure of log4net as reported as LOG4NET-342,
+ log4net supports a way to evaluate if it was configured and also to evaluate messages generated on startup since 1.2.11. To
+ check if log4net was started and configured properly one can check the property
+ log4net.Repository.ILoggerRepository.Configured and enumerate the configuration messages as follows:
+
+ If you are not getting events delivered to the event log this usually indicates
+ a permissions problem. Basically if the event log does not exist the EventLogAppender
+ tries to create it, but you need local administrator permissions to create event logs
+ (just to write into the right bit of the registry). You don't need administrator
+ permissions to log to an existing event log, but it must exist. If you are using the
+ event log from a web application or service using the event log can be a little tricky.
+
+
+ A web application will run as the user account ASPNET. This account deliberately has
+ few permissions to reduce the chances of someone hacking into the web server. While the
+ account has permission to write to the event log it does not have permission to create
+ event sources (registry create and write access), which are needed to write to the event log.
+
+
+ There are a couple of solutions:
+
+
+
+
+ Make the ASPNET user a member of the Administrators group. This will work because the
+ user will then have the required permissions. This is not recommended
+ for production use.
+
+
+
+
+ As the event source only needs to be created once for the machine, create an installer
+ and configure it to create the event source.
+ The installer will need to be run as Administrator (don't they all). See
+ System.Diagnostics.EventLogInstaller in the Microsoft .NET
+ Framework SDK for an example of how to create a simple event log installer.
+
+ The web application runs as a special user account on the web server
+ called ASPNET. This account has restricted permissions to protect the
+ web server from attacks. By default this account may not have permission
+ to write to the file system. Make sure that the ASPNET account has
+ permission to create and write to files in the directory chosen for
+ logging.
+
+ A windows service runs as a user account specified in the services
+ control panel. This account may have restricted permissions, make
+ sure that the account has permission to create and write to files
+ in the directory chosen for logging.
+
+
+ A windows service is launched by windows. The current directory in
+ a service is set to the windows system directory (e.g.
+ C:\Windows\System32). If you are loading
+ the configuration file from the current directory then be aware
+ that this path will not be the location of your assemblies.
+ The best way to get the path to your assemblies is to use
+ AppDomain.BaseDirectory.
+ Note that the log4net internals never use the current directory.
+
+ This problem has been reported by several people as issue
+ LOG4NET-178.
+ The issue seems to be caused by a broken LOG4NET configuration
+ or a timing problem caused by an application shutdown event that
+ floats in late after an application start event and thus LOG4NET
+ stops logging immediately after it has been started.
+
+
+ The first thing step to troubleshoot problems is enabling
+ the log4net internal debugging features as described
+ here
+ and fix all errors that pop up. If the problem still persists,
+ this comment
+ suggests to move the LOG4NET configuration out of the
+ web.config into a separate file
+ like log4net.config. Finally,
+ if both previous steps did not help and the problem still
+ occurs, you can try to work around the event timing problem
+ by invoking the configuration call from the class constructor as described in
+ this comment.
+
+ If you need to use ODBC to connect to your database then please note that the
+ ADO.NET ODBC drivers are not included in the standard .NET framework redistributable.
+ You can download the drivers from microsoft download at:
+ ODBC .NET Data Provider.
+
+ If you have identified a bug, please report it
+ via our
+ Issue
+ Tracker
+ . You may want to check it hasn't
+ been reported before by searching the existing
+ issues.
+
+ If you use attributes to configure log4net then
+ the order by which assemblies are loaded may
+ determine whether you attributes are used or
+ not. Assembly load order may be different in
+ DEBUG and RELEASE mode.
+
+
+
+ As stated in
+ the
+ manual
+ the attribute will only be read for
+ the first assembly that tries to use log4net.
+ So it is important that you obtain your
+ ILog instance as early as possible.
+
+
+
+ For a command line application "as early as
+ possible" probably is the class holding the
+ Main method, for a Web-Application
+ it would be your Global.asax class
+ and for a Windows Service it would be the class
+ deriving from ServiceBase.
+
+ You may have overlooked initialization code for
+ log4net in your application. log4net can be
+ initialized explicitly by calling one of the
+ configurators
+ (e.g. BasicConfigurator or
+ XmlConfigurator in the
+ log4net.Config namespace, or
+ implicitly by including the
+ [XmlConfiguratorAttribute] in the
+ assembly where log4net is first used.
+
+
+
+ See
+ the
+ manual
+ for more information. If you use
+ attributes to configure log4net then the order
+ by which assemblies are loaded may determine
+ whether you attributes are used or not.
+ Assembly load order may be different in DEBUG
+ and RELEASE mode. See also
+ log4net doesn't log when built
+ in RELEASE mode
+ .
+
- Starting with .NET 4.5.1 ADO.NET has added
- connection resiliency which is supposed to
- re-establish the connection as part if the
- framework. As a result log4net doesn't know the
- connection is broken and will never attempt to
- re-establish the connection.
-
-
- Unfortunately re-connecting doesn't seem to be
- working reliably. A workaround may be to add
- ConnectRetryCount=0 to your
- connection string.
-
- log4net is a tool to help the programmer output log statements to a
- variety of output targets. In case of problems with an application,
- it is helpful to enable logging so that the problem can be located.
- With log4net it is possible to enable logging at runtime without
- modifying the application binary. The log4net package is designed so
- that log statements can remain in shipped code without incurring a
- high performance cost. It follows that the speed of logging (or
- rather not logging) is crucial.
-
-
- At the same time, log output can be so voluminous that it quickly becomes
- overwhelming. One of the distinctive features of log4net is the notion of
- hierarchical loggers. Using these loggers it is possible to selectively
- control which log statements are output at arbitrary granularity.
-
-
- log4net is designed with two distinct goals in mind: speed and flexibility
-
-
-
-
-
-
Support for multiple frameworks
-
Output to multiple logging targets
-
Hierarchical logging architecture
-
XML Configuration
-
Dynamic Configuration
-
Logging Context
-
Proven architecture
-
Modular and extensible design
-
High performance with flexibility
-
-
+
+
-
-
- log4net runs on all ECMA CLI 1.0 compatible runtimes.
- log4net has specific builds for the following frameworks:
-
The "Client Profile" builds are stripped down
- versions of the "normal" builds that don't contain any
- ASP.NET releated code - which for example means the
- %aspnet-* patterns and the
- AspNetTraceAppender are not available.
+
+
+ log4net is a tool to help the programmer output log statements to a
+ variety of output targets. In case of problems with an application,
+ it is helpful to enable logging so that the problem can be located.
+ With log4net it is possible to enable logging at runtime without
+ modifying the application binary. The log4net package is designed so
+ that log statements can remain in shipped code without incurring a
+ high performance cost. It follows that the speed of logging (or
+ rather not logging) is crucial.
+
+
+ At the same time, log output can be so voluminous that it quickly becomes
+ overwhelming. One of the distinctive features of log4net is the notion of
+ hierarchical loggers. Using these loggers it is possible to selectively
+ control which log statements are output at arbitrary granularity.
+
+
+ log4net is designed with two distinct goals in mind: speed and flexibility
+
+
-
- *Not
- supported by the binary release but can be built
- from the source release.
-
-
+
+
+
Support for multiple frameworks
+
Output to multiple logging targets
+
Hierarchical logging architecture
+
XML Configuration
+
Dynamic Configuration
+
Logging Context
+
Proven architecture
+
Modular and extensible design
+
High performance with flexibility
+
+
-
-
- log4net ships with the following appenders (not on all frameworks):
-
-
-
-
-
- Type
-
- Description
-
-
-
log4net.Appender.AdoNetAppender
-
- Writes logging events to a database using either prepared statements or stored
- procedures.
-
-
-
-
log4net.Appender.AnsiColorTerminalAppender
-
- Writes color highlighted logging events to a an ANSI terminal window.
-
-
-
-
log4net.Appender.AspNetTraceAppender
-
- Writes logging events to the ASP trace context. These can then be rendered at
- the end of the ASP page or on the ASP trace page.
-
-
-
-
log4net.Appender.ColoredConsoleAppender
-
- Writes color highlighted logging events to the application's Windows Console.
-
-
-
-
log4net.Appender.ConsoleAppender
-
- Writes logging events to the application's Console. The events may go to either
- the standard our stream or the standard error stream.
-
-
-
-
log4net.Appender.DebugAppender
-
- Writes logging events to the .NET system.
-
-
-
-
log4net.Appender.EventLogAppender
-
- Writes logging events to the Windows Event Log.
-
-
-
-
log4net.Appender.FileAppender
-
- Writes logging events to a file in the file system.
-
-
-
-
log4net.Appender.LocalSyslogAppender
-
- Writes logging events to the local syslog service (UNIX only).
-
-
-
-
log4net.Appender.MemoryAppender
-
- Stores logging events in an in memory buffer.
-
-
-
-
log4net.Appender.NetSendAppender
-
- Writes logging events to the Windows Messenger service. These messages are
- displayed in a dialog on a users terminal.
-
-
-
-
log4net.Appender.OutputDebugStringAppender
-
- Writes logging events to the debugger. If the application has no
- debugger, the system debugger displays the string. If the application has no
- debugger and the system debugger is not active, the message is ignored.
-
-
-
-
log4net.Appender.RemoteSyslogAppender
-
- Writes logging events to a remote syslog service using UDP networking.
-
-
-
-
log4net.Appender.RemotingAppender
-
- Writes logging events to a remoting sink using .NET remoting.
-
-
-
-
log4net.Appender.RollingFileAppender
-
- Writes logging events to a file in the file system. The RollingFileAppender can
- be configured to log to multiple files based upon date or file size
- constraints.
-
-
-
-
log4net.Appender.SmtpAppender
-
- Sends logging events to an email address.
-
-
-
-
log4net.Appender.SmtpPickupDirAppender
-
- Sends logging events to an email
- address but writes the emails to a
- configurable directory rather than
- sending them directly via SMTP.
-
-
-
-
log4net.Appender.TelnetAppender
-
- Clients connect via Telnet to receive logging events.
-
-
-
-
log4net.Appender.TraceAppender
-
- Writes logging events to the .NET trace system.
-
-
-
-
log4net.Appender.UdpAppender
-
- Sends logging events as connectionless UDP datagrams to a remote host or a
- multicast group using a UdpClient.
-
-
-
-
-
A special log4net.Appender.ForwardingAppender can
- be used to wrap another appender, for example to
- attach additional filters.
-
+
+
+ log4net runs on net462 or higher and any framework supporting netstandard2.0.
+
+
-
-
- Hierarchical logging is an ideal fit with component based development.
- Each component has its own of logger. When individually tested, the
- properties of these loggers may be set as the developer requires.
- When combined with other components, the loggers inherit the properties
- determined by the integrator of the components. One can selectively elevate
- logging priorities on one component without affecting the other components.
- This is useful when you need a detailed trace from just a single component
- without crowding the trace file with messages from other components. All
- this can be done through configuration files; no code changes are required.
-
-
+
+
+ log4net ships with the following appenders:
+
+
+
+
+
+ Type
+
+
+ Description
+
+
+
+
log4net.Appender.AdoNetAppender
+
+ Writes logging events to a database using either prepared statements or stored
+ procedures.
+
+
+
+
log4net.Appender.AnsiColorTerminalAppender
+
+ Writes color highlighted logging events to a an ANSI terminal window.
+
+
+
+
log4net.Appender.AspNetTraceAppender
+
+ Writes logging events to the ASP trace context. These can then be rendered at
+ the end of the ASP page or on the ASP trace page.
+
+
+
+
log4net.Appender.ColoredConsoleAppender
+
+ Writes color highlighted logging events to the application's Windows Console.
+
+
+
+
log4net.Appender.ConsoleAppender
+
+ Writes logging events to the application's Console. The events may go to either
+ the standard our stream or the standard error stream.
+
+
+
+
log4net.Appender.DebugAppender
+
+ Writes logging events to the .NET system.
+
+
+
+
log4net.Appender.EventLogAppender
+
+ Writes logging events to the Windows Event Log.
+
+
+
+
log4net.Appender.FileAppender
+
+ Writes logging events to a file in the file system.
+
+
+
+
log4net.Appender.LocalSyslogAppender
+
+ Writes logging events to the local syslog service (UNIX only).
+
+
+
+
log4net.Appender.MemoryAppender
+
+ Stores logging events in an in memory buffer.
+
+
+
+
log4net.Appender.NetSendAppender
+
+ Writes logging events to the Windows Messenger service. These messages are
+ displayed in a dialog on a users terminal.
+
+
+
+
log4net.Appender.OutputDebugStringAppender
+
+ Writes logging events to the debugger. If the application has no
+ debugger, the system debugger displays the string. If the application has no
+ debugger and the system debugger is not active, the message is ignored.
+
+
+
+
log4net.Appender.RemoteSyslogAppender
+
+ Writes logging events to a remote syslog service using UDP networking.
+
+
+
+
log4net.Appender.RemotingAppender
+
+ Writes logging events to a remoting sink using .NET remoting.
+
+
+
+
log4net.Appender.RollingFileAppender
+
+ Writes logging events to a file in the file system. The RollingFileAppender can
+ be configured to log to multiple files based upon date or file size
+ constraints.
+
+
+
+
log4net.Appender.SmtpAppender
+
+ Sends logging events to an email address.
+
+
+
+
log4net.Appender.SmtpPickupDirAppender
+
+ Sends logging events to an email
+ address but writes the emails to a
+ configurable directory rather than
+ sending them directly via SMTP.
+
+
+
+
log4net.Appender.TelnetAppender
+
+ Clients connect via Telnet to receive logging events.
+
+
+
+
log4net.Appender.TraceAppender
+
+ Writes logging events to the .NET trace system.
+
+
+
+
log4net.Appender.UdpAppender
+
+ Sends logging events as connectionless UDP datagrams to a remote host or a
+ multicast group using a UdpClient.
+
+
+
+
+
+ A special log4net.Appender.ForwardingAppender can
+ be used to wrap another appender, for example to
+ attach additional filters.
+
+
-
-
- log4net is configured using an XML configuration file. The configuration
- information can be embedded within other XML configuration files
- (such as the application's .config file) or in a separate file. The
- configuration is easily readable and updateable while retaining the
- flexibility to express all configurations.
-
-
- Alternatively log4net can be configured programmatically.
-
-
+
+
+ Hierarchical logging is an ideal fit with component based development.
+ Each component has its own of logger. When individually tested, the
+ properties of these loggers may be set as the developer requires.
+ When combined with other components, the loggers inherit the properties
+ determined by the integrator of the components. One can selectively elevate
+ logging priorities on one component without affecting the other components.
+ This is useful when you need a detailed trace from just a single component
+ without crowding the trace file with messages from other components. All
+ this can be done through configuration files; no code changes are required.
+
+
-
-
- log4net can monitor its configuration file for changes and dynamically
- apply changes made by the configurator. The logging levels, appenders,
- layouts, and just about everything else can be adjusted at runtime.
- In many cases it is possible to diagnose application issues without
- terminating the process in question. This can a very valuable tool in
- investigating issues with deployed applications.
-
-
+
+
+ log4net is configured using an XML configuration file. The configuration
+ information can be embedded within other XML configuration files
+ (such as the application's .config file) or in a separate file. The
+ configuration is easily readable and updateable while retaining the
+ flexibility to express all configurations.
+
+
+ Alternatively log4net can be configured programmatically.
+
+
-
-
- log4net can be used to collect logging context data in a way that is transparent
- to the developer at the point of logging. The GlobalContext and the
- ThreadContext allow the application to store contextual data that is
- attached to logging messages. For instance, in a web service,
- once the caller is authenticated the username of the caller could be
- stored in a ThreadContext property. This property would then be automatically
- logged as part of each subsequent logging message made from the same thread.
-
-
+
+
+ log4net can monitor its configuration file for changes and dynamically
+ apply changes made by the configurator. The logging levels, appenders,
+ layouts, and just about everything else can be adjusted at runtime.
+ In many cases it is possible to diagnose application issues without
+ terminating the process in question. This can a very valuable tool in
+ investigating issues with deployed applications.
+
+
-
-
- log4net is based on the highly successful Apache log4j™ logging library,
- in development since 1996. This popular and proven architecture has
- so far been ported to 12 languages.
-
-
-
-
-
+
+
+ log4net can be used to collect logging context data in a way that is transparent
+ to the developer at the point of logging. The GlobalContext and the
+ ThreadContext allow the application to store contextual data that is
+ attached to logging messages. For instance, in a web service,
+ once the caller is authenticated the username of the caller could be
+ stored in a ThreadContext property. This property would then be automatically
+ logged as part of each subsequent logging message made from the same thread.
+
+
+
+
+
+ log4net is based on the highly successful Apache log4j™ logging library,
+ in development since 1996. This popular and proven architecture has
+ so far been ported to 12 languages.
+
- log4net is built on a number of different frameworks. Each new version of the frameworks add
- new features. To take advantage of these new features we must build log4net using the
- appropriate framework. We also maintain builds compatible with older versions of the frameworks.
-
-
- It is important to remember that the .NET frameworks support backward compatibility, that is
- a new version of the framework will run binary assemblies that were targeted to previous versions
- of the framework.
-
-
- While the number of different builds available may seem confusing, you only need to select the
- nearest build for your platform that is equal to or earlier than your chosen deployment framework.
- If you intend to deploy your application on the Microsoft® .NET Framework 1.0 don't pick the
- log4net build that is built against the Microsoft .NET Framework 1.1 because the .NET framework
- does not guarantee forward compatibility only backward compatibility.
-
-
- log4net is regularly built by its developers on the following frameworks:
-
- log4net should also build on the following
- frameworks but binaries are not created by the
- developers and source compatibility can not be
- guaranteed:
-
- For most of these frameworks a log4net assembly targeting the framework is supplied. Although it's
- perfectly possible to use the .NET Framework 3.5 version of log4net on the .NET Framework 4.0, having
- an assembly that really targets a specific framework allows us to use features in that framework that
- are not available in other frameworks or remove features from log4net that are not supported in a
- specific framework.
-
-
- There are no assemblies targeting the Compact
- Framework 1.0/2.0, .NET Framework or Mono 1.x or
- Microsoft Shared Source CLI 1.0 in the binary
- release, but they can be built from the source
- release.
-
-
-
-
-
- The appenders available to each framework depend on the functionality of the
- framework and the platform it runs on:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Appender
-
.NET Framework 1.0
-
.NET Framework 1.1
-
.NET Framework 2.0
-
.NET Framework 3.5
-
.NET Framework 4.0
-
.NET Framework 4.5
-
.NET Framework 3.5 Client Profile
-
.NET Framework 4.0 Client Profile
-
.NET Standard 1.3
-
.NET CF 1.0
-
.NET CF 2.0
-
Mono
-
Shared Source CLI 1.0
-
CLI 1.0 Compatible
-
-
-
AdoNetAppender
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
-
x
-
x
-
x
-
-
x
-
-
-
AnsiColorTerminalAppender
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
-
-
AspNetTraceAppender
-
x
-
x
-
x
-
x
-
x
-
x
-
-
-
-
-
-
x
-
-
x
-
-
-
BufferingForwardingAppender
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
-
-
ColoredConsoleAppender
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
-
-
-
-
-
-
-
-
ConsoleAppender
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
-
-
DebugAppender
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
-
-
EventLogAppender
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
-
-
-
x
-
-
x
-
-
-
FileAppender
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
-
-
ForwardingAppender
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
-
-
LocalSyslogAppender
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
-
-
x
-
-
x
-
-
-
ManagedColoredConsoleAppender
-
-
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
-
-
x
-
-
-
-
-
MemoryAppender
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
-
-
NetSendAppender
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
-
-
-
-
-
-
-
-
OutputDebugStringAppender
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
-
-
-
-
-
RemoteSyslogAppender
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
-
-
RemotingAppender
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
-
-
-
x
-
x
-
x
-
-
-
RollingFileAppender
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
-
-
SmtpAppender
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
-
-
-
x
-
-
x
-
-
-
SmtpPickupDirAppender
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
-
-
TelnetAppender
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
-
-
TraceAppender
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
-
-
UdpAppender
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
x
-
-
-
-
-
-
-
-
- Targets netstandard-1.3 and thus doesn't support
- a few things that work on Mono or the classical
- .NET platform.
-
-
Things that are not supported in log4net
- for .NET Standard 1.3:
-
-
the ADO.NET appender
-
anything related to ASP.NET (trace appender
- and several pattern converters)
-
.NET Remoting
-
the colored console appender
-
the event log appender
-
The NetSendAppender
-
The SMTP appender
-
DOMConfigurator
-
stack trace patterns
-
access to appSettings (neither
- the log4net section itself nor using the
- AppSettingsPatternConverter)
-
Access to "special paths" using the
- EnvironmentFolderPathPatternConverter
-
Impersonation of Windows accounts
-
-
-
log4net.LogicalThreadContext and
- the associated properties and stack classes use
- AsyncLocal rather than
- CallContext. Prior to log4net 2.0.8
- they haven't been supported for .NET Standard at
- all.
-
-
-
-
- none
-
-
-
-
-
- none
-
-
-
-
-
- none
-
-
-
-
-
- none
-
-
-
-
-
- none
-
-
-
-
-
- none
-
-
-
-
-
- As of log4net 1.2.11 this version is identical
- to the .NET 3.5 version without support for
- ASP.NET specific appenders and patterns.
-
-
-
-
-
- As of log4net 1.2.11 this version is identical
- to the .NET 4.0 version without support for
- ASP.NET specific appenders and patterns.
-
-
-
-
-
Assembly attributes
-
- The .NET Compact Framework 1.0 does not support retrieving assembly level
- attributes, therefore all log4net configuration attributes were removed from
- the .NET Compact Framework 1.0 version of log4net.
-
-
- For Smart-device applications, the log4net system can be configured by passing
- the location of the log4net configuration file to the
- log4net.Config.XmlConfigurator.Configure(FileInfo)
- method in the entry point of the application.
-
-
For example:
-
-
-namespace TestApp
-{
- using System.IO;
-
- public class EntryPoint
- {
- /// <summary>
- /// Application entry point.
- /// </summary>
- public static void Main()
- {
- // Uncomment the next line to enable log4net internal debugging
- // log4net.Util.LogLog.InternalDebugging = true;
-
- // This will instruct log4net to look for a configuration file
- // called config.log4net in the root directory of the device
- log4net.Config.XmlConfigurator.Configure(new FileInfo(@"\config.log4net"));
-
- ...
-
- // This will shutdown the log4net system
- log4net.LogManager.Shutdown();
- }
- }
-}
-
-
Notification events
-
- The .NET Compact Framework 1.0 does not support notification events during the
- application shutdown, therefore log4net cannot automatically hook the
- application shutdown notification.
-
-
- Applications will need to programmatically shutdown the log4net system during
- the application's shutdown using the
- log4net.LogManager.Shutdown()
- method in order to prevent losing logging events.
- See the code above for an example.
-
-
FileSystemWatcher
-
- The .NET Compact Framework 1.0 does not support the
- System.IO.FileSystemWatcher
- class. As a result, the
- XmlConfiguratorAttribute.Watch
- property and the
- XmlConfigurator.ConfigureAndWatch
- methods are not available. Watching changes to the log4net configuration
- file is not supported on the .NET Compact Framework 1.0.
-
-
UserName
-
- The .NET Compact Framework 1.0 does not support the
- System.Security.Principal.WindowsIdentity class.
- This is used to capture the current thread's user identity. Therefore
- the LoggingEvent.UserName property will return the value
- "NOT AVAILABLE".
-
-
Identity
-
- The .NET Compact Framework 1.0 does not support the
- System.Security.Principal.IPrincipal interface.
- This is used to capture the current thread's user identity. Therefore
- the LoggingEvent.Identity property will return the value
- "NOT AVAILABLE".
-
-
Environment variables
-
- The .NET Compact Framework 1.0 does not support retrieving environment
- variables, therefore it's not possible to substitute environment variables in
- parameter values when using the .NET Compact Framework 1.0 version of log4net.
-
-
Serialization
-
- The .NET Compact Framework 1.0 does not support serialization, therefore none of
- the log4net classes in the .NET Compact Framework 1.0 version are serializable.
-
-
LoggingEvent.Domain
-
- The .NET Compact Framework 1.0 does not support AppDomain functionality. The
- friendly name for the current AppDomain is stored in the LoggingEvent.Domain
- property and is accessed using the %a pattern of the
- PatternLayout. On the .NET Compact Framework 1.0 this
- value is generated by taking the file name for the application's primary module.
-
-
-
-
- See notes for .NET Compact Framework 1.0
-
-
-
-
- There are 2 separate builds of log4net for mono; Mono 1.0, built using the C# compiler in a mode
- which is compatible with the CLI 1.0 language specification, and; Mono 2.0, built using the .NET
- 2.0 extensions to the C# language.
-
-
-
-
- none
-
-
-
-
- none
-
-
-
-
- none
-
-
-
-
- none
-
-
-
-
-
-
-
FileSystemWatcher
-
- SSCLI 1.0 does not support the
- System.IO.FileSystemWatcher
- class. As a result, the
- XmlConfiguratorAttribute.Watch
- property and the
- XmlConfigurator.ConfigureAndWatch
- methods are not available. Watching changes to the log4net configuration
- file is not supported on SSCLI 1.0.
-
-
UserName
-
- SSCLI 1.0 does not support the
- System.Security.Principal.WindowsIdentity class.
- This is used to capture the current thread's user identity. Therefore
- the LoggingEvent.UserName property will return the value
- "NOT AVAILABLE".
-
-
Identity
-
- SSCLI 1.0 does not support the
- System.Security.Principal.IPrincipal interface.
- This is used to capture the current thread's user identity. Therefore
- the LoggingEvent.Identity property will return the value
- "NOT AVAILABLE".
-
-
-
-
-
- This build of log4net is designed to run on any ECMA CLI 1.0 compatible runtime.
- The assembly does not support any platform specific features. The build includes
- the common subset of functionality found in the .NET 1.0 and Mono 1.0 builds.
- The output assembly is built using the Microsoft .NET 1.0 compiler and library.
-
-
- The log4net CLI 1.0 assembly is runtime compatible with the following frameworks:
-
-
-
Microsoft .NET Framework 1.0 (and higher)
-
Mono 1.0 (and higher)
-
-
- Only a Release build is generated for this configuration because the assembly
- debugging information has not been standardized.
-
-
+ href="https://logging.apache.org/security.html">
+ security page
+ of the Logging project
+ .
+
+
-
-
This page lists all security vulnerabilities fixed in
+
+
+ This page lists all security vulnerabilities fixed in
released versions of Apache log4net. Each
vulnerability is given a security impact rating by the
development team - please note that this rating may vary from
platform to platform. We also list the versions of log4net the
- flaw is known to affect, and where a flaw has not
- been verified list the version with a question mark.
+ flaw is known to affect, and where a flaw has not
+ been verified list the version with a question mark.
+
-
Please note that binary patches are never provided. If you
+
+ Please note that binary patches are never provided. If you
need to apply a source code patch, use the building
instructions for the log4net version that you are
- using.
+ using.
+
-
If you need help on building log4net or other help
+
+ If you need help on building log4net or other help
on following the instructions to mitigate the known
vulnerabilities listed here, please send your questions to the
- public Logging Users mailing
- list.
If you have encountered an unlisted security vulnerability
+
+ If you have encountered an unlisted security vulnerability
or other unexpected behaviour that has security impact, or if
the descriptions here are incomplete, please report them
- privately to the Apache Security Team. Thank you.
+ privately to the Apache Security Team. Thank you.
+
-
+
-
-