Log4net Version 2.0.12.0 Download
Dalene Huizenga
It looks like the main cause for this problem is the way log4net requires it's config file in the assembly info of the class library. WPF doesn't seem to like that. Referencing log4net in the wpf app itself caused the log4net config file to be overwritten for me, as the wpf app is later in the build order and generates a default log4net config file.
I had the same problem with log4net when creating a new WPF project and adding a reference to another project that referenced log4net. I resolved the issue by adding the log4net.dll to the GAC using these instructions: -us/library/dkkx7f79.aspx
I had the same problem. I still don't fully understand it, but I can tell you how I solved my problem.I had a unit test project B with a project reference to project A, which references log4net. So to me the gibberish means when Visual Studio is trying to create the .accessor file for the unit test project, it reflects on project A. This means it tries to load project A's references, but the assembly loader can't find it because I don't have log4net in the GAC, just locally for project A to reference. In my case, adding log4net to my DEVPATH (GAC would work, too) was the solution.
Apache log4net 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.
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.
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.
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.
If you are configuring log4net programmatically (i.e. not using one of the built-in configurators) you must set the ILoggerRepository.Configured property to true once you have configured the repository.
The Hierarchy specific data schema and implementation could be has now been moved to the log4net.Repository.Hierarchy namespace. The bootstrap code for these configurators remains in the log4net.Config namespace.
The 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.
Did you add the 1.2.11.0 log4net as a reference in your project and recompile it afterwards? We've been doing this on projects where we have been using an older version of the log4net.dll file, which worked fine.
No, I added Umbraco to my project using the package manager console. So I guess it's the binary distribution, and my feeble attempts at adding references to different versions of log4net have not been compiled into the project...
Was having the same problem with Log4Net and finally found the cause. In my project downloaded Log4Net from the Apache site ( ) and copied the log4Net.DLL in folder log4net-1.2.11-bin-newkey\log4net-1.2.11\bin\net\4.0\release. This DLL is the same version 1.2.11.0 but noticed has different file size to the one that comes with Umbraco 6 installation.
I'm experiencing the same issue. I have a domain project which relies on Castle Windsor to inject the log4net facility into my code and this relies on log4net 1.2.10 but Umbraco is using, what seems to be a patched version of 1.2.11.
Redirecting all assemblies to 1.2.11 from Umbraco installation but it won't work as the patched version has a null public key token
Forking castle core log4net integration to use the umbraco patched log4net assembly which won't build as it doesnt have a Strong Name
Please try to install the corresponding log4net NuGet package and check the code about the Crystal Report. Please share us more information like code snippets and minimal reproducible sample to check further.
How exactly do i install the log4net NuGet package and run it so that the error message no longer appears and I am not quite sure about the crystal report code. I will share more code snippets as I still have the same Issue.
Error List.pdf