Log4net Version 1.2.10.0

[Sadoth Royer]

Apachelog4net 2.0.8 fixes a LockRecursionException that could happen inside the FileAppender under certain circumstances. It also adds support for LogicalThreadContext to the .NET Standard build based on AsyncLocal rather than CallContext.

Apache log4net 2.0.7 fixes a glitch in nuget packaging and is otherwise identical to 2.0.6 (apart from the copyright year and assembly version). If you are not using the nuget package there is no reason to upgrade.

The Apache log4net team is now responsible for the nuget package, we've changed the version number of this release to align the version numbers. Release 2.0.6 is supposed to be compatible with 1.2.15.

Starting with 2.0.6 .NET Core - or more precisely .NET Standard 1.3 - has become a supported platform. Please note that several features of log4net are not available when using the .NET Core version, see framework support for details.

In the log4net.Config namespace the DOMConfigurator , DOMConfiguratorAttribute, DomainAttribute, and AliasDomainAttribute have been marked as obsolete. These types are still available and functional in this release.

The XmlConfigurator and XmlConfiguratorAttribute types replace DOMConfigurator and DOMConfiguratorAttribute. The RepositoryAttribute and AliasRepositoryAttribute types replace DomainAttribute and AliasDomainAttribute.

Renamed AdoNetAppender, AspNetTraceAppender, SmtpAppender, Iso8601DateFormatter, MdcFilter, and NdcFilter. Note that the config file type resolver is case insensitive so this is only a breaking change for code that programmatically creates a type that has been renamed.

A new log4net assembly is built that targets all CLI 1.0 compatible runtimes. This build is essentially a common subset of the Mono 1.0 and .NET 1.0 builds. It is built using the MS .NET 1.0 compiler and libraries but does not use any platform specific APIs.

Logging contexts can be used to record contextual data that is relevant to the current process. Logging contexts are both an extension of the concepts embodied in the MDC and NDC and a replacement for them. The MDC and NDC have been reimplemented to use the ThreadContext as storage.

The logging contexts provide a single unified view that cuts across different scopes within an application. The contexts are layered in the following order of narrowing scope: GlobalContext, ThreadContext, LogicalThreadContext, and LoggingEvent. Context values specified in a narrower scope hide the matching value in a wider scope.

The above config defines a custom pattern called myConverter which is bound to the TestApp.MyPatternConverter, TestApp type. This type must extend the log4net.Util.PatternConverter base class. The custom pattern can then be used in the pattern string.

Log4net supports configuring No-Touch deployment applications using the XmlConfiguratorAttribute. If a relative config file or extension is specified then this is resolved relative to the deployment URI.

Appenders that interact with controlled platform resources, e.g. files, can be configured to use a separate security context when accessing these resources. The calling thread may not have appropriate privileges to access the resource a custom SecurityContext can be used to elevate the privileges of the appender. The WindowsSecurityContext is used to specify alternative credentials on the Windows platform.

The AnsiColorTerminalAppender writes events to the application's ANSI terminal window. It can be configured to specify the text and background colors for different level events. Note that Console applications running on Windows do not have an ANSI terminal window and should use the ColoredConsoleAppender instead.

The TelnetAppender accepts socket connections and streams logging messages back to the client. The output is provided in a telnet-friendly way so that a log can be monitored over a TCP/IP socket. This allows simple remote monitoring of application logging.

The FileAppender (and by extension the RollingFileAppender) now support pluggable file locking models. The default model, ExclusiveLock, maintains the current exclusive file locking behavior. An alternative model, MinimalLock, can be used to support writing to a single output file from multiple processes.

To resolve cross platform and cross version issues we have changed the log4net assembly to use a common name for all frameworks. The assembly friendly name is now log4net. The builds for each framework can now be differentiated by the assembly title. This includes the name of the framework that the assembly was built on.

The LoggingEvent now supports fine grained fixing of data that needs to be accessed outside the append context, e.g. when an event is buffered. The new Fix property takes a combination of the FixFlags enumeration values.

If you are configuring log4net programmatically (i.e. not using one of the built-in configurators) you must set the ILoggerRepository.Configured property to true once you have configured the repository.

Updated default behavior of DefaultRepositorySelector. Assemblies are now by default placed into the default domain. To specify another domain, the DomainAttribute must be used. This is the opposite behavior to what was previously available. If you were previously specifying the DomainAttribute.UseDefaultDomain property then you should remove it, and if the default behavior is now sufficient, you do not need to specify the DomainAttribute at all.

Appenders can add additional information to the events they are logging. The RemotingAppender and the SMTPAppender both add a 'hostname' property to the events. These properties can be accessed using the PatternLayout with the %Pname syntax.

The Hierarchy specific data schema and implementation could be has now been moved to the log4net.Repository.Hierarchy namespace. The bootstrap code for these configurators remains in the log4net.Config namespace.

This change to the implementation of the DOMConfiguratorAttribute should allow the configuration of multiple assemblies to be accomplished more easily, especially when developing web applications (ASP.NET).

The instance methods from Category have moved to the Logger class. The static methods from Category have moved to the LogManager class. The Category class still exists but for backward compatibility only. Changed interface ICategoryFactory to ILoggerFactory and the implementation class DefaultCategoryFactory to DefaultLoggerFactory .

The Priority class has been replaced by the Level class. The Priority class still exists for backward compatibility only. The Level class implements a static pool of Level objects. The Level class is sealed and serializable.

Delivers LoggingEvents to a remote interface. This can be used to collect distributed logging into a single log file. There is an example remoting sink that receives the logging events, see examples\net\remoting\RemotingServer for details.

The DefaultRenderer now has support for rendering exceptions to a string. This includes nested exceptions. The RendererMap is now used to render exceptions in the LoggingEvent. This allows the rendering of specific exceptions to be enhanced by specific renderers.

This interface is used by SMTPAppender and RemotingAppender to determine if a LoggingEvent meets a set of user defined criteria. These appenders use the interface to determine whether or not to deliver the current buffer of events to their listener. The interface is implemented by the LevelEvaluator class, which triggers above a set level.

As the Category and Priority classes have been replaced by the Logger and Level classes. The DOMConfigurator has been updated to allow the and elements to be used in place of the and elements. The old elements are still accepted for backward compatibility.

The LogManager supports multiple logging domains. The LogManager uses an instance of the IRepositorySelector class to map from domains to ILoggerRepository instances. The default implementation is to have a separate ILoggerRepository for each domain. When a call is made to the static methods on LogManager the domain can be specified (as a string) or the domain can be inferred automatically from the calling assembly. The default behavior is for each assembly loaded into the process to have its own domain and ILoggerRepository. These can each be configured separately. This allows standalone assemblies to use log4net without conflicting with other modules in the process. The domain for the assembly is configured using metadata attributes defined on the assembly.

I'm using vs2010 and crystal report version 13.0.2000.0 ,system 64bit crystal report runtime 64bit.my application is running fine on development machine but when i'm deploying on server getting this error

Could not load file or assembly 'log4net, Version=1.2.10.0, Culture=neutral, PublicKeyToken=692fbea5521e1304' or one of its dependencies. The system cannot find the file specified.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

and I have checked GAC assembly I didn't find log4net.dll and even in my system I have search all and tried various things like changing runtime version and uploading lo4net dll from apache but no luck.

If you don't see log4net.dll in %systemdrive%\windows\assembly\ on the machine you are attempting to deploy it on, it is likely you haven't successfully installed the redistributable for Crystal Reports for .Net Framework 4.0

You need to install crystal Report's RunTime version (version 33 and above) and 4.8 framework.Interestingly, both 32 and 64 versions must be installed on 64-bit Windows.But the issue that exists is that it is installed on server 2016 and above, and on Windows server 2012, I did not try to solve the problem.

From what I understand, this means that the actual file located (that is, log4net.dll in my bin directory) does not match the version expected based on some assembly configuration. The problem I'm having is that I cannot locate where this file is being referenced.

3a8082e126