From 6e885f14341bb0500744ce4d7c032e20d86f5dfb Mon Sep 17 00:00:00 2001 From: Jan Friedrich Date: Mon, 4 Mar 2024 11:31:14 +0100 Subject: [PATCH] removed legacy target framework from docs --- doc/BUILDING.md | 21 +- doc/CONTRIBUTING.md | 9 +- src/site/xdoc/release/building.xml | 144 +- src/site/xdoc/release/example-apps.xml | 724 +++--- src/site/xdoc/release/faq.xml | 2424 ++++++++++--------- src/site/xdoc/release/features.xml | 541 ++--- src/site/xdoc/release/framework-support.xml | 999 ++------ src/site/xdoc/release/security-reports.xml | 70 +- 8 files changed, 2017 insertions(+), 2915 deletions(-) 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. +

+
-
- +
+ diff --git a/src/site/xdoc/release/example-apps.xml b/src/site/xdoc/release/example-apps.xml index ca148885..f4e04324 100644 --- a/src/site/xdoc/release/example-apps.xml +++ b/src/site/xdoc/release/example-apps.xml @@ -17,455 +17,281 @@ limitations under the License. --> - - Nicko Cadell - Apache log4net: Examples - + + Nicko Cadell + Apache log4net: Examples + - - - -
- -
-

- 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. +

+

+

+
+ +
+ +
+ diff --git a/src/site/xdoc/release/faq.xml b/src/site/xdoc/release/faq.xml index c23931e8..25d36fd4 100644 --- a/src/site/xdoc/release/faq.xml +++ b/src/site/xdoc/release/faq.xml @@ -17,151 +17,176 @@ limitations under the License. --> - - Nicko Cadell - Apache log4net: Frequently Asked Questions - - - - - - - -
-
- -
-

- 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. -

-
-

Back to Top

- - -
-

- 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. -

-
-

Back to Top

- - -
-

- 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. -

-
-

Back to Top

- - -
-

- There is a directory containing examples in log4net\examples. - The examples are broken down by framework. -

-
-

Back to Top

- - -
-
    -
  • - log4net is optimized for speed.
    • -
  • - log4net is based on a named logger hierarchy.
    • -
  • - log4net is fail-stop but not reliable.
    • -
  • - log4net is thread-safe.
    • -
  • - log4net is not restricted to a predefined set of facilities.
    • -
  • - Logging behavior can be set at runtime using a configuration file. - Configuration files are in XML format.
    • -
  • - log4net is designed to handle exceptions from the start.
    • -
  • - log4net can direct its output to many sinks including: a file, the console, the NT EventLog or even e-mail.
    • -
  • - log4net categorizes logging into levels: DEBUG, INFO, WARN, ERROR and FATAL.
    • -
  • - The format of the log output can be easily changed by implementing a new layout class.
    • -
  • - The target of the log output as well as the writing strategy can be altered by - writing a new appender class.
    • -
  • - log4net supports multiple output appenders per logger.
    • -
-

- See the features overview document for more information on the features of log4net. -

-
-

Back to Top

- - -
-

- Yes, log4net is thread-safe. -

-
-

Back to Top

- - -
-

- 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 -

- + Nicko Cadell + Apache log4net: Frequently Asked Questions + + + + + + + +
+
+ +
+

+ 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. +

+
+

+ Back to Top +

+ + +
+

+ 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. +

+
+

+ Back to Top +

+ + +
+

+ log4net runs on net462 or higher and any framework supporting netstandard2.0. +

+
+

+ Back to Top +

+ + +
+

+ There is a directory containing examples in log4net\examples. + The examples are broken down by framework. +

+
+

+ Back to Top +

+ + +
+
    +
  • + log4net is optimized for speed. +
    • +
  • + log4net is based on a named logger hierarchy. +
    • +
  • + log4net is fail-stop but not reliable. +
    • +
  • + log4net is thread-safe. +
    • +
  • + log4net is not restricted to a predefined set of facilities. +
    • +
  • + Logging behavior can be set at runtime using a configuration file. + Configuration files are in XML format. +
    • +
  • + log4net is designed to handle exceptions from the start. +
    • +
  • + log4net can direct its output to many sinks including: a file, the console, the NT EventLog or even e-mail. +
    • +
  • + log4net categorizes logging into levels: DEBUG, INFO, WARN, ERROR and FATAL. +
    • +
  • + The format of the log output can be easily changed by implementing a new layout class. +
    • +
  • + The target of the log output as well as the writing strategy can be altered by + writing a new appender class. +
    • +
  • + log4net supports multiple output appenders per logger. +
    • +
+

+ See the features overview document for more information on the features of log4net. +

+
+

+ Back to Top +

+ + +
+

+ Yes, log4net is thread-safe. +

+
+

+ Back to Top +

+ + +
+

+ 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 +

+ + -

- The first field is the number of milliseconds elapsed since the start of the - program. The second field is the thread outputting the log statement. The third - field is the level of the log statement. The fourth field is the rightmost - two components of the name of the logger making the log request. The fifth field (just - before the '-') is the nested diagnostic context (NDC). Note the - nested diagnostic context may be empty as in the first two statements. The text - after the '-' is the message of the statement. -

-
-

Back to Top

- - -
-

- The logger concept lies at the heart of log4net's configuration. Loggers are organized into a - hierarchy and give the programmer run-time control on which logging statements - are printed or not. -

-

- Loggers are assigned levels through the configuration of log4net. A log statement is - routed through to the appender depending on its level and its logger. -

-
-

Back to Top

- - -
-

- Contrary to the GNU Public License (GPL) the Apache Software License does not - make any claims over your extensions. By extensions, we mean totally new code - that invokes existing log4net code. You are free to do whatever you wish with - your proprietary log4net extensions. In particular, you may choose to - never release your extensions to the wider public. For details see the - Apache License, Version 2.0. -

-

- We are very careful not to unnecessarily change the log4net client API so that newer log4net - releases are backward compatible with previous versions. We are a lot less - scrupulous with the internal log4net API. Thus, if your extension is designed to - work with the internals of a specific log4net version, then when the next release - of log4net comes out, you will probably need to adapt your proprietary extensions to the - new release. Thus, you will be forced to spend precious resources in order to - keep up with log4net changes. This is commonly referred to as the "stupid-tax". - By donating the code and making it part of the standard distribution, you save - yourself the unnecessary maintenance work. -

-

- If your extensions are useful then someone will eventually write an extension - providing the same or very similar functionality. Your development effort will - be wasted. -

-

- Unless the proprietary log4net extension is business critical, there is little - reason for not donating your extensions back to the project. -

-
-

Back to Top

- - -
-
    -
  1. - Stick to the existing indentation style even if you hate it. -

    - Alternating between indentation styles makes it hard to understand the source - code. Make it hard on yourself but easier on others. -

    -
    2. -
  2. - Thoroughly test your code. -

    - There is nothing more irritating than finding the bugs in debugging (i.e. logging) code. -

    -
    3. -
  3. - Keep it simple, small and fast. -

    - It's all about the application not about logging. -

    -
    4. -
  4. - Did I mention sticking with the indentation style?
    5. -
-
-

Back to Top

- - -
-

- log4net is a port of the popular Apache log4j™ logging library. - The initial port was done in June 2001, since then we have tried to remain in the - spirit of the original log4j. See the log4net history page for more details. -

-
-

Back to Top

- - -
-

- The log4net home page is a good place to start. -

-
-

Back to Top

- -
-

- Starting with log4net 1.2.11 there are two - different binary distributions, - oldkey and newkey. -

- -

- The oldkey distribution contains - assemblies signed with the same strong name key - that was used to sign the assemblies of log4net - 1.2.10 and earlier. This strong name key is only - available to log4net developers. -

- -

- The newkey distribution contains - assemblies signed with the strong name key - available from log4net's - svn area or inside the source distribution. - Everybody can create assemblies that have the same - strong name. -

- -

- For open source projects it is important that you - can create your own patched version of a product - and use it instead of the official release. This - is something that is now possible if the - newkey is used throughout. -

- -

- The oldkey distribution is mostly - only for people who work with third-party - dependencies that require one of the earlier - releases of log4net and can't be recompiled to use - the new strong name. If you start a new project - or can recompile all your dependencies we strongly - recommend you use the newkey - assemblies. -

- -

- If you are creating an assembly that is likely to - be combined with other assemblies that depend on - the old strong name, then it is better you use the - oldkey assemblies as well. -

- -

- We currently plan to distribute the new-key - assembly under a different name while providing - old and newkey log4net.dll assemblies - holding type forwards to the new assembly. This - may create a cleaner migration path for projects - that have dependencies using both versions. - At the moment such projects will either need to - use the GAC or create sub-directories inside the - application directory and configure assembly - probing with a privatePath. -

- -

- Note that the "new" strong name no longer provides - any kind of authenticity. If you want to be sure - you have the "real" Apache log4net, download the binary - release from one of the mirrors and verify the PGP - signature. -

- -
-

Back to Top

- -
- -
- -
-

- Logging behavior can be set using configuration files which are parsed at runtime. - Using configuration files the programmer can define loggers and set their - levels. -

-

- Configuration files are specified in XML. See log4net.Config.XmlConfigurator - for more details. -

-

- See the various log4net.Layout and log4net.Appender - components for specific configuration options. -

-
-

Back to Top

- - -
-

- Setting the Threshold on the Hierarchy to Level OFF will disable all - logging from that Hierarchy. This can be done in the log4net configuration file - by setting the "threshold" attribute on the log4net configuration element to "OFF". - For example: -

- ]]> -
-

Back to Top

- -
-

- log4net uses public properties to configure components such as - Appenders, Layouts, Loggers etc. -

-

- Thus, any writable public property in on the appender corresponds to a - configurable option. For example, in RollingFileAppender the - public int MaxSizeRollBackups { set; } property corresponds to - the MaxSizeRollBackups option. -

-

- Layouts options are also defined by their writable properties. Same goes for most - other log4net components. -

-
-

Back to Top

- - -
-

- Yes it is. Setting the Threshold option of any appender extending - AppenderSkeleton, (most log4net appenders extend - AppenderSkeleton) will filter out all log events - with a lower level than the value of the threshold option. -

-

- For example, setting the threshold of an appender to DEBUG will also allow INFO, - WARN, ERROR and FATAL messages to log along with DEBUG messages. (DEBUG is the - lowest level). This is usually acceptable as there is little use for DEBUG - messages without the surrounding INFO, WARN, ERROR and FATAL messages. - Similarly, setting the threshold of an appender to ERROR will filter out DEBUG, - INFO and WARN messages but not ERROR or FATAL messages. -

-

- This policy usually best encapsulates what the user actually wants to do, as - opposed to her mind-projected solution. -

-

- If you must filter events by exact level match, then you can attach a - LevelMatchFilter to any appender to filter out logging - events by exact level match. -

-
-

Back to Top

- - -
-

- Yes. The XmlConfigurator supports automatic - reloading through the ConfigureAndWatch APIs. See the API - documentation for more details. -

-
-

Back to Top

- - -
-

- Yes. When specifying the type in the configuration file you can give the assembly - qualified name of the type. For example: -

- ]]> -

- The .NET runtime will try to locate the assembly called MyAssembly. - How .NET locates assemblies is beyond the scope of this FAQ. -

-

- When loading an assembly from the GAC the fully qualified assembly name, - including the version, culture and public key must be specified. This is - in the standard syntax supported by System.Type.GetType. - See the next FAQ on how to get the version and public key for an assembly. -

-
-

Back to Top

- - -
-

- The fully qualified name for an assembly includes the version, culture and - public key. The public key is derived from the strong name used to identify - the publisher. When referencing an assembly from the GAC the fully qualified - name must be used. To get the version, culture and public key you can use a - tool like the excellent .NET Reflector from Lutz Roeder available from - http://www.aisto.com/roeder/dotnet. -

-
-

Back to Top

- - -
-

- Newlines in the config file need to be escaped using an XML numeric character reference. - The sequence that represents a CR LF is 
 
. The following example adds - a header and footer to the output each followed by a newline. -

- + +

+ The first field is the number of milliseconds elapsed since the start of the + program. The second field is the thread outputting the log statement. The third + field is the level of the log statement. The fourth field is the rightmost + two components of the name of the logger making the log request. The fifth field (just + before the '-') is the nested diagnostic context (NDC). Note the + nested diagnostic context may be empty as in the first two statements. The text + after the '-' is the message of the statement. +

+
+

+ Back to Top +

+ + +
+

+ The logger concept lies at the heart of log4net's configuration. Loggers are organized into a + hierarchy and give the programmer run-time control on which logging statements + are printed or not. +

+

+ Loggers are assigned levels through the configuration of log4net. A log statement is + routed through to the appender depending on its level and its logger. +

+
+

+ Back to Top +

+ + +
+

+ Contrary to the GNU Public License (GPL) the Apache Software License does not + make any claims over your extensions. By extensions, we mean totally new code + that invokes existing log4net code. + You are free to do whatever you wish with + your proprietary log4net extensions. + In particular, you may choose to + never release your extensions to the wider public. For details see the + Apache License, Version 2.0. +

+

+ We are very careful not to unnecessarily change the log4net client API so that newer log4net + releases are backward compatible with previous versions. We are a lot less + scrupulous with the internal log4net API. Thus, if your extension is designed to + work with the internals of a specific log4net version, then when the next release + of log4net comes out, you will probably need to adapt your proprietary extensions to the + new release. Thus, you will be forced to spend precious resources in order to + keep up with log4net changes. This is commonly referred to as the "stupid-tax". + By donating the code and making it part of the standard distribution, you save + yourself the unnecessary maintenance work. +

+

+ If your extensions are useful then someone will eventually write an extension + providing the same or very similar functionality. Your development effort will + be wasted. +

+

+ Unless the proprietary log4net extension is business critical, there is little + reason for not donating your extensions back to the project. +

+
+

+ Back to Top +

+ + +
+
    +
  1. + Stick to the existing indentation style even if you hate it. +

    + Alternating between indentation styles makes it hard to understand the source + code. Make it hard on yourself but easier on others. +

    +
    2. +
  2. + Thoroughly test your code. +

    + There is nothing more irritating than finding the bugs in debugging (i.e. logging) code. +

    +
    3. +
  3. + Keep it simple, small and fast. +

    + It's all about the application not about logging. +

    +
    4. +
  4. + Did I mention sticking with the indentation style? +
    5. +
+
+

+ Back to Top +

+ + +
+

+ log4net is a port of the popular Apache log4j™ logging library. + The initial port was done in June 2001, since then we have tried to remain in the + spirit of the original log4j. See the log4net history page for more details. +

+
+

+ Back to Top +

+ + +
+

+ The log4net home page is a good place to start. +

+
+

+ Back to Top +

+ +

+ Back to Top +

+ +
+ +
+ +
+

+ Logging behavior can be set using configuration files which are parsed at runtime. + Using configuration files the programmer can define loggers and set their + levels. +

+

+ Configuration files are specified in XML. See log4net.Config.XmlConfigurator + for more details. +

+

+ See the various log4net.Layout and log4net.Appender + components for specific configuration options. +

+
+

+ Back to Top +

+ + +
+

+ Setting the Threshold on the Hierarchy to Level OFF will disable all + logging from that Hierarchy. This can be done in the log4net configuration file + by setting the "threshold" attribute on the log4net configuration element to "OFF". + For example: +

+ + ]]> + +
+

+ Back to Top +

+ +
+

+ log4net uses public properties to configure components such as + Appenders, Layouts, Loggers etc. +

+

+ Thus, any writable public property in on the appender corresponds to a + configurable option. For example, in RollingFileAppender the + public int MaxSizeRollBackups { set; } property corresponds to + the MaxSizeRollBackups option. +

+

+ Layouts options are also defined by their writable properties. Same goes for most + other log4net components. +

+
+

+ Back to Top +

+ + +
+

+ Yes it is. Setting the Threshold option of any appender extending + AppenderSkeleton, (most log4net appenders extend + AppenderSkeleton) will filter out all log events + with a lower level than the value of the threshold option. +

+

+ For example, setting the threshold of an appender to DEBUG will also allow INFO, + WARN, ERROR and FATAL messages to log along with DEBUG messages. (DEBUG is the + lowest level). This is usually acceptable as there is little use for DEBUG + messages without the surrounding INFO, WARN, ERROR and FATAL messages. + Similarly, setting the threshold of an appender to ERROR will filter out DEBUG, + INFO and WARN messages but not ERROR or FATAL messages. +

+

+ This policy usually best encapsulates what the user actually wants to do, as + opposed to her mind-projected solution. +

+

+ If you must filter events by exact level match, then you can attach a + LevelMatchFilter to any appender to filter out logging + events by exact level match. +

+
+

+ Back to Top +

+ + +
+

+ Yes. The XmlConfigurator supports automatic + reloading through the ConfigureAndWatch APIs. See the API + documentation for more details. +

+
+

+ Back to Top +

+ + +
+

+ Yes. When specifying the type in the configuration file you can give the assembly + qualified name of the type. For example: +

+ + ]]> + +

+ The .NET runtime will try to locate the assembly called MyAssembly. + How .NET locates assemblies is beyond the scope of this FAQ. +

+

+ When loading an assembly from the GAC the fully qualified assembly name, + including the version, culture and public key must be specified. This is + in the standard syntax supported by System.Type.GetType. + See the next FAQ on how to get the version and public key for an assembly. +

+
+

+ Back to Top +

+ + +
+

+ The fully qualified name for an assembly includes the version, culture and + public key. The public key is derived from the strong name used to identify + the publisher. When referencing an assembly from the GAC the fully qualified + name must be used. To get the version, culture and public key you can use a + tool like the excellent .NET Reflector from Lutz Roeder available from + http://www.aisto.com/roeder/dotnet. +

+
+

+ Back to Top +

+ + +
+

+ Newlines in the config file need to be escaped using an XML numeric character reference. + The sequence that represents a CR LF is 
 
. The following example adds + a header and footer to the output each followed by a newline. +

+ +
-]]> -
-

Back to Top

- - -
-

- Log4net supports a pattern syntax for setting string properties similar to the - PatternLayout used to format the output messages. - This pattern syntax can be used by specifying type="log4net.Util.PatternString" - on the string property in the config file. This tells the config parser to pass the - value to the PatternString type before converting the result - to a string. For details on the patterns supported see the - PatternString SDK Reference. -

-

- The following example sets the file name for a FileAppender to include the - current process id by specifying the %processid pattern in the - File property. -

- ]]> + +
+

+ Back to Top +

+ + +
+

+ Log4net supports a pattern syntax for setting string properties similar to the + PatternLayout used to format the output messages. + This pattern syntax can be used by specifying type="log4net.Util.PatternString" + on the string property in the config file. This tells the config parser to pass the + value to the PatternString type before converting the result + to a string. For details on the patterns supported see the + PatternString SDK Reference + . +

+

+ The following example sets the file name for a FileAppender to include the + current process id by specifying the %processid pattern in the + File property. +

+ + -]]> -
-

Back to Top

- - -
- -
- -
-

- Yes, there are. -

-

- You can name logging loggers by locality. It turns out that - instantiating a logger in each class, with the logger name equal to the - fully-qualified name of the class, is a useful and straightforward approach of - defining loggers. This approach has many benefits: -

-
    -
  • - It is very simple to implement.
    • -
  • - It is very simple to explain to new developers.
    • -
  • - It automatically mirrors your application's own modular design.
    • -
  • - It can be further refined at will.
    • -
  • - Printing the logger automatically gives information on the locality of the - log statement.
    • -
-

- However, this is not the only way for naming loggers. A common alternative - is to name loggers by functional areas. For example, the - "database" logger, "remoting" logger, "security" logger, or the "XML" - logger. -

-

- You may choose to name loggers by functionality and subcategorize by - locality, as in "DATABASE.MyApp.MyClass" or - "DATABASE.MyApp.MyModule.MyOtherClass". -

-

- You are totally free in choosing the names of your loggers. The - log4net package merely allows you to manage your names in a hierarchy. However, - it is your responsibility to define this hierarchy. -

-

- Note: by naming loggers by locality one tends to name things by - functionality, since in most cases the locality relates closely to - functionality. -

-
-

Back to Top

- - -
-

- You can easily retrieve the fully-qualified name of a class in a static block - for class X, with the statement typeof(X).Name. - Note that X is the class name and span an instance. - However because the LogManager.GetLogger method is overloaded - to take an instance of Type as well as string - usually only the type of the class is required. -

-

- Here is the suggested usage template: -

- ]]> + +
+

+ Back to Top +

+ + +
+ +
+ +
+

+ Yes, there are. +

+

+ You can name logging loggers by locality. It turns out that + instantiating a logger in each class, with the logger name equal to the + fully-qualified name of the class, is a useful and straightforward approach of + defining loggers. This approach has many benefits: +

+
    +
  • + It is very simple to implement. +
    • +
  • + It is very simple to explain to new developers. +
    • +
  • + It automatically mirrors your application's own modular design. +
    • +
  • + It can be further refined at will. +
    • +
  • + Printing the logger automatically gives information on the locality of the + log statement. +
    • +
+

+ However, this is not the only way for naming loggers. A common alternative + is to name loggers by functional areas. For example, the + "database" logger, "remoting" logger, "security" logger, or the "XML" + logger. +

+

+ You may choose to name loggers by functionality and subcategorize by + locality, as in "DATABASE.MyApp.MyClass" or + "DATABASE.MyApp.MyModule.MyOtherClass". +

+

+ You are totally free in choosing the names of your loggers. The + log4net package merely allows you to manage your names in a hierarchy. However, + it is your responsibility to define this hierarchy. +

+

+ Note: by naming loggers by locality one tends to name things by + functionality, since in most cases the locality relates closely to + functionality. +

+
+

+ Back to Top +

+ + +
+

+ You can easily retrieve the fully-qualified name of a class in a static block + for class X, with the statement typeof(X).Name. + Note that X is the class name and span an instance. + However because the LogManager.GetLogger method is overloaded + to take an instance of Type as well as string + usually only the type of the class is required. +

+

+ Here is the suggested usage template: +

+ + -

- An equivalent and more portable solution, though slightly longer, is to use the declaring type - of the static constructor. -

- + +

+ An equivalent and more portable solution, though slightly longer, is to use the declaring type + of the static constructor. +

+ + -

- 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 + +

+ 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. -

-
-

Back to Top

- - -
-

- For some logger log, writing, -

- -

- 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. +

+
+

+ Back to Top +

+ + +
+

+ For some logger log, writing, +

+ + + +

+ 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. -

-
-

Back to Top

- - -
-

- 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. +

+
+

+ Back to Top +

+ + +
+

+ 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. -

-
-

Back to Top

- - -
-

- 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. -

-
-

Back to Top

- - -
-

- It is quite nontrivial to define the semantics of a "removed" logger which is - still referenced by the user. -

-
-

Back to Top

- - -
-

- 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. +

+
+

+ Back to Top +

+ + +
+

+ 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. +

+
+

+ Back to Top +

+ + +
+

+ It is quite nontrivial to define the semantics of a "removed" logger which is + still referenced by the user. +

+
+

+ Back to Top +

+ + +
+

+ 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. -

-
-

Back to Top

- - -
-

- 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. -

-
-

Back to Top

- - -
-

- 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. -

-
-

Back to Top

- - -
- -
- -
-

- 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. -

-
-

Back to Top

- - -
-

- 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. -

-
-

Back to Top

- -
- -
- -
-

- 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: -

    - 
    -<?xml version="1.0" encoding="utf-8" ?>
-<configuration>
-    <appSettings>
-        <add key="log4net.Internal.Debug" value="true"/>
-    </appSettings>
-</configuration>
    -

    - 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: -

- 
-<configuration>
-    ...
-    
-    <system.diagnostics>
-        <trace autoflush="true">
-            <listeners>
-                <add 
-                    name="textWriterTraceListener" 
-                    type="System.Diagnostics.TextWriterTraceListener" 
-                    initializeData="C:\tmp\log4net.txt" />
-            </listeners>
-        </trace>
-    </system.diagnostics>
-
-    ...
-</configuration>
-

- Make sure that the process running your application has permission - to write to this file. -

-
-

Back to Top

- -
-

- 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(!log4net.LogManager.GetRepository().Configured)
-{
-	// log4net not configured
-	foreach(log4net.Util.LogLog message in log4net.LogManager.GetRepository().ConfigurationMessages.Cast<log4net.Util.LogLog&bg;())
-	{
-		// evaluate configuration message
-	}
-}
-
-
-
-

Back to Top

- -
-

- 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: -

-
    -
  1. -

    - 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. -

    -
    2. -
  2. -

    - 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. -

    -
    3. -
-

- There is a Microsoft Knowledge Base article that covers this issue and how to resolve - it. - PRB: "Requested Registry Access Is Not Allowed" Error Message When ASP.NET - Application Tries to Write New EventSource in the EventLog. -

-
-

Back to Top

- - -
-

- 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. -

-
-

Back to Top

- - -
-

- 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. -

-
-

Back to Top

- - -
-

- 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. -

-
-

Back to Top

- - -
-

- For details on the different ways in which ADO.NET can connect to a database see: - Connecting to a Data Source Using ADO.NET. -

-

- 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. -

-
-

Back to Top

- - -
-

- 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. -

-
-

Back to Top

- -
-

- 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. -

-
-

Back to Top

- -
-

- 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. -

- -
-

Back to Top

- -
Back to Top +

+ + +
+

+ 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. +

+
+

+ Back to Top +

+ + +
+

+ 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. +

+
+

+ Back to Top +

+ + +
+ +
+ +
+

+ 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. +

+
+

+ Back to Top +

+ + +
+

+ 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. +

+
+

+ Back to Top +

+ +
+ +
+ +
+

+ 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: +

    +
    + 
    +                  <?xml version="1.0" encoding="utf-8" ?>
+                  <configuration>
+                  <appSettings>
+                  <add key="log4net.Internal.Debug" value="true"/>
+                  </appSettings>
+                  </configuration>
+
    +
    +

    + 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: +

+
+ 
+              <configuration>
+              ...
+
+              <system.diagnostics>
+              <trace autoflush="true">
+              <listeners>
+              <add
+              name="textWriterTraceListener"
+              type="System.Diagnostics.TextWriterTraceListener"
+              initializeData="C:\tmp\log4net.txt" />
+              </listeners>
+              </trace>
+              </system.diagnostics>
+
+              ...
+              </configuration>
+
+
+

+ Make sure that the process running your application has permission + to write to this file. +

+
+

+ Back to Top +

+ +
+

+ 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(!log4net.LogManager.GetRepository().Configured)
+              {
+              // log4net not configured
+              foreach(log4net.Util.LogLog message in log4net.LogManager.GetRepository().ConfigurationMessages.Cast<log4net.Util.LogLog&bg;())
+              {
+              // evaluate configuration message
+              }
+              }
+
+
+
+

+ Back to Top +

+ +
+

+ 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: +

+
    +
  1. +

    + 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. +

    +
    2. +
  2. +

    + 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. +

    +
    3. +
+

+ There is a Microsoft Knowledge Base article that covers this issue and how to resolve + it. + PRB: "Requested Registry Access Is Not Allowed" Error Message When ASP.NET + Application Tries to Write New EventSource in the EventLog + . +

+
+

+ Back to Top +

+ + +
+

+ 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. +

+
+

+ Back to Top +

+ + +
+

+ 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. +

+
+

+ Back to Top +

+ + +
+

+ 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. +

+
+

+ Back to Top +

+ + +
+

+ For details on the different ways in which ADO.NET can connect to a database see: + Connecting to a Data Source Using ADO.NET. +

+

+ 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. +

+
+

+ Back to Top +

+ + +
+

+ 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. +

+
+

+ Back to Top +

+ +
+

+ 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. +

+
+

+ Back to Top +

+ +
+

+ 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 + . +

+ +
+

+ Back to Top +

+ +
-

- 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. -

-

- For details see + 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. +

+

+ For details see LOG4NET-442 -

-
-
- -
- -
-

- There is a good discussion of this topic on Robert McLaws blog: - Building a Better Server Control Experience, Part 2. -

-
- -
-

- Starting with version 2.0.6 we provide Nuget packages. For earlier - versions Jiří Činčura has kindly created - Nuget packages. -

-
-

Back to Top

- -
- +

+
+
+ +
+ +
+

+ There is a good discussion of this topic on Robert McLaws blog: + Building a Better Server Control Experience, Part 2. +

- +
+

+ Starting with version 2.0.6 we provide Nuget packages. For earlier + versions Jiří Činčura has kindly created + Nuget packages. +

+
+

+ Back to Top +

+ +
+ +
+ + diff --git a/src/site/xdoc/release/features.xml b/src/site/xdoc/release/features.xml index c42b7235..f6432e1f 100644 --- a/src/site/xdoc/release/features.xml +++ b/src/site/xdoc/release/features.xml @@ -17,298 +17,271 @@ limitations under the License. --> - - Nicko Cadell - Apache log4net: Features - + + Nicko Cadell + Apache log4net: Features + - + - -
- -
-

- 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: -

-
    -
  • .NET Core 1.0 - using netstandard-1.3
    • -
  • Microsoft® .NET Framework 1.0*
    • -
  • Microsoft .NET Framework 1.1*
    • -
  • Microsoft .NET Framework 2.0
    • -
  • Microsoft .NET Framework 3.5
    • -
  • Microsoft .NET Framework 4.0
    • -
  • Microsoft .NET Framework 4.5
    • -
  • Microsoft .NET Framework 3.5 Client Profile
    • -
  • Microsoft .NET Framework 4.0 Client Profile
    • -
  • Microsoft .NET Compact Framework 1.0*
    • -
  • Microsoft .NET Compact Framework 2.0*
    • -
  • Mono 1.0*
    • -
  • Mono 2.0
    • -
  • Mono 3.5
    • -
  • Mono 4.0
    • -
  • Microsoft Shared Source CLI 1.0*
    • -
  • CLI 1.0 Compatible*
    • -
-

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. +

+
+ +
+ diff --git a/src/site/xdoc/release/framework-support.xml b/src/site/xdoc/release/framework-support.xml index 15a42ae8..ba3c1027 100644 --- a/src/site/xdoc/release/framework-support.xml +++ b/src/site/xdoc/release/framework-support.xml @@ -17,867 +17,146 @@ limitations under the License. --> - - Nicko Cadell - Apache log4net: Supported Frameworks - - - - - -
- -
-

- 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: -

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
FrameworkWebsite
.NET Core 1.0 providing .NET Standard 1.3https://dotnet.github.io/
Microsoft .NET Framework 2.0http://msdn.microsoft.com/en-us/netframework/
Microsoft .NET Framework 3.5http://msdn.microsoft.com/en-us/netframework/
Microsoft .NET Framework 4.0http://msdn.microsoft.com/en-us/netframework/
Microsoft .NET Framework 3.5 Client Profilehttp://msdn.microsoft.com/en-us/library/cc656912.aspx
Microsoft .NET Framework 4.0 Client Profilehttp://msdn.microsoft.com/en-us/library/cc656912.aspx
Microsoft .NET Framework 4.5http://msdn.microsoft.com/en-us/netframework/
Mono 2.0http://www.mono-project.com
Mono 3.5http://www.mono-project.com
Mono 4.0http://www.mono-project.com
-
-

- log4net should also build on the following - frameworks but binaries are not created by the - developers and source compatibility can not be - guaranteed: -

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
FrameworkWebsite
Microsoft .NET Framework 1.0http://msdn.microsoft.com/en-us/netframework/
Microsoft .NET Framework 1.1http://msdn.microsoft.com/en-us/netframework/
Microsoft .NET Compact Framework 1.0http://msdn2.microsoft.com/en-us/netframework/aa497273.aspx
Microsoft .NET Compact Framework 2.0http://msdn2.microsoft.com/en-us/netframework/aa497273.aspx
Mono 1.0http://www.mono-project.com
Microsoft Shared Source CLI 1.0http://msdn.microsoft.com/en-us/library/ms973879.aspx
CLI 1.0 Compatiblehttp://msdn.microsoft.com/en-us/netframework/aa569283.aspx
-
-

- 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.0MonoShared Source CLI 1.0CLI 1.0 Compatible
AdoNetAppenderxxxxxxxxxxxx
AnsiColorTerminalAppenderxxxxxxxxxxxxxx
AspNetTraceAppenderxxxxxxxx
BufferingForwardingAppenderxxxxxxxxxxxxxx
ColoredConsoleAppenderxxxxxxxx
ConsoleAppenderxxxxxxxxxxxxxx
DebugAppenderxxxxxxxxxxxxxx
EventLogAppenderxxxxxxxxxx
FileAppenderxxxxxxxxxxxxxx
ForwardingAppenderxxxxxxxxxxxxxx
LocalSyslogAppenderxxxxxxxxxxx
ManagedColoredConsoleAppenderxxxxxxxx
MemoryAppenderxxxxxxxxxxxxxx
NetSendAppenderxxxxxxxx
OutputDebugStringAppenderxxxxxxxxxxx
RemoteSyslogAppenderxxxxxxxxxxxxxx
RemotingAppenderxxxxxxxxxxx
RollingFileAppenderxxxxxxxxxxxxxx
SmtpAppenderxxxxxxxxxx
SmtpPickupDirAppenderxxxxxxxxxxxxxx
TelnetAppenderxxxxxxxxxxxxxx
TraceAppenderxxxxxxxxxxxxxx
UdpAppenderxxxxxxxxxxxxxx
-
-
- -
-
-

- 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. -

-
- -
+ + Nicko Cadell + Apache log4net: Supported Frameworks + + + + + +
+ +
+

+ log4net is regularly built by its developers on the following frameworks: +

+ +
+ + + + + + + + + + + + + + + + + +
FrameworkWebsite
Microsoft .NET 8 providing .NET Standard 2.0 + https://dotnet.microsoft.com/en-us/download/dotnet/8.0 +
Microsoft .NET Framework 4.6.2 + http://msdn.microsoft.com/en-us/netframework/ +
+
+
+ +
+

+ Currently all appenders are available in each supported framework: +

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Appender
AdoNetAppender
AnsiColorTerminalAppender
AspNetTraceAppender
BufferingForwardingAppender
ColoredConsoleAppender
ConsoleAppender
DebugAppender
EventLogAppender
FileAppender
ForwardingAppender
LocalSyslogAppender
ManagedColoredConsoleAppender
MemoryAppender
NetSendAppender
OutputDebugStringAppender
RemoteSyslogAppender
RemotingAppender
RollingFileAppender
SmtpAppender
SmtpPickupDirAppender
TelnetAppender
TraceAppender
UdpAppender
+
+
+ +
+
+

+ none +

+
+
+

+ none +

+
+
- + diff --git a/src/site/xdoc/release/security-reports.xml b/src/site/xdoc/release/security-reports.xml index 30c57bd8..e1e64663 100644 --- a/src/site/xdoc/release/security-reports.xml +++ b/src/site/xdoc/release/security-reports.xml @@ -17,48 +17,64 @@ limitations under the License. --> - - Apache log4net: Security Reports - Logging Documentation Team - - -
-

For information about reporting or asking questions about + + Apache log4net: Security Reports + Logging Documentation Team + + +

+

+ For information about reporting or asking questions about security problems, please see the security page - of the Logging project.

-
+ 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.

+ 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. +

-
+
-
-

Please report any errors or omissions to the dev mailing list.

-
- +
+

+ Please report any errors or omissions to the dev mailing list. +

+
+