Log4Net can log to multiple backends, including multiple database backends. I've seen a situation before where a patch to improve performance for postgresql negatively impacted mssql users (something to do with parameter initialisation). To this end, we should have a github action which runs log4net against multiple database backends and verifies that the results are correct for both, perhaps also recording timings and referring to expected timings to raise flags about any massive change in runtime.

Public classes and interfaces should get nullable annotations so that callers will be warned when passing null values.

List of breaking changes

#129 - Part 4 of nullable and modernization

• interface log4net.Appender.AppenderCollection.IAppenderCollectionEnumerator is now obsolete and must be replaced by IEnumerator<IAppender>
• log4net.Appender.MemoryAppender.m_eventsList (protected field) was changed from ArrayList to List<LoggingEvent>
  • for getting m_eventsList.SyncRoot you need to cast it: ((ICollection)m_eventsList).SyncRoot

Issue for preparing the first preview of 3.0.0

I have revamped the Download, Support, and Security pages of Logging Services (LS) such that they now cover all LS projects. In the Log4j website, I have wired all associated links to there and I have replaced all overlapping content to point to there. Would you consider implementing the following changes for the left menu of the Log4net website?

1. Point "Download" to the LS Download page
2. Remove the "Security Reports"
3. Point the "Security" in the left menu to the LS Security page
4. Replace "Mailing Lists", "Issue Tracking" links with a "Support" link pointing to the LS Support page

This commit introduced after 2.0.15 results in an NRE during some shutdown cases where m_lockingModel is null during Close/Dispose.

The simplistic fix is to add a check to FileAppender. The better fix is to enable nullability on FileAppender, RollingFileAppender, and their unit tests, and fix all nullability problems.

A fix is needed as a 2.0.17 package in addition to the proposed 3.0 package.

Log4net supports a lot of really old runtimes, including net2.0 and net3.5 CE (Compact Edition) which can be notoriously difficult to install on windows (I've been lucky and unlucky - today, it "just worked" without intervention, but previously, I've crafted the included powershell scripts to install .net framework 3.5.

These targets make it impossible (as far as I know, and I've tried) to build on non-windows hosts. However, if we could reduce the targeted runtime list to:

• net462
• netstandard2.0

then we could support all supported versions of .net (at time of writing, the lowest supported netfx version is 4.6.2) because we can use Mono on non-windows hosts to provide the api to compile system functionality against (see MonoForFramework.targets)

Apart from quicker builds & testing times, this would be highly beneficial in that it would make contributing to log4net much easier.

On one hand, I'd really like to maintain as much compatibility as possible, but on the other, I'd like to remove hurdles for prospective devs (and myself 😅 )

There are numerous parts of the code that are marked with [Obsolete] attributes. Additionally there is code that may or may not any longer be in use, such as NDC (src/log4net/NDC.cs). Ideally with the major version change the deprecations should be removed.

This is where we are told the documentation is:
https://logging.apache.org/log4net/

All the top level links work, but as soon as you click through to a second level, the link is broken e.g.
https://logging.apache.org/log4net/release/sdk/index.html

It would be highly beneficial to the project to have automatic test runs (npm test) for every commit. To this end, a GitHub action that (eventually) invokes npm test would be fantastic.

After upgrading to ASP.NET core 8, the logs using the property %thread print a generic thread name instead of the thread ID.

The commit ab74a0a seems to be related to a fix for the issue. Is there any timeline/date for when this will be release?

I was using the package in .net7.0 without problems. However, after updating to .net8.0, my program throws error. When I unchecked the trimming unused code option, there was no error, but it increases output file size very much. How can I solve it?

The RELEASING.md document attempts to layout each and every step, in order, that is required to get log4net updates to the users.

There are a lot of steps, but we can break the process up into a few sections where some could be automated:

1. update the documentation with any new information - could be partially automated: if nothing else, the new site for the new version should be created from the old one, leaving the only duty to update with changes. More often than not, the API doesn't change, so this would be automated for all intents and purposes, but obviously we might want to stop here to make modifications
2. new npm script: npm run prepare-release -> would do steps 2-12 of the linked RELEASING.md document
3. raise a vote on the logging mailing list - perhaps this could be "semi-automated" by generating an email from a template and invoking the system email handler, but this might not be worth it. At any rate, the voting process cannot be automated, so we'd have to stop here anyway
4. new npm script: npm run publish-release -> would do steps 16-19, once the vote has passed

build logic can be written in typescript or javascript, by adding gulp-style tasks in files under local-tasks (see existing tasks under that folder; tasks are run by zarro and I'm always happy to assist with this. To see a new shell task, run npm run zarro -- -- --create-task (the two --'s are required to get past npm's argument handlers and pass on to zarro)

We're using Log4Net (2.0.15.0-.NET 4.5) in WCF services hosted in IIS. On our production environments from time to times we're experiencing crash of the application pool with following error:

Exception: System.IndexOutOfRangeException

Message: Index was outside the bounds of the array.

StackTrace: at System.Collections.ArrayList.Add(Object value)
at log4net.Util.LogReceivedEventHandler.Invoke(Object source, LogReceivedEventArgs e)
at log4net.Util.LogLog.OnLogReceived(Type source, String prefix, String message, Exception exception)
at log4net.Util.LogLog.Debug(Type source, String message)
at log4net.Appender.AppenderSkeleton.Finalize()

So it seems the LogLog.Debug statement in the finalize method can fail in some circumstances...

If you run npm run run-dotnet-core-tests, the test assembly should be run with dotnet instead of the nunit runner. This should be used to verify that cross-framework code works as expected. Unfortunately, at the moment, it looks like doing this doesn't pick up any tests - this requires some investigation.

Ultimately, we should move away from the nunit-console -based run to running via dotnet for all targets. The first step would be getting this script (run-dotnet-core-tests) to work as expected.

*** I have raised an issue with both Xamarin.Forms and Log4net as ambiguity where the issue lies***

Log4net 2.0.15
Xamarin.Forms 5.0.0.2622
Android 14.0 (34)
VS 2022 17.8.4

This seems to only occur since updating to Android 14.0.

When archiving the project The following error is thrown:

Severity Code Description Project File Line Suppression State Details Error Mono.Linker.OutputException: Failed to write 'Xamarin.Android.Project\obj\Release\130\android\assets\log4net.dll ---> System.IO.IOException: The process cannot access the file 'Xamarin.Android.Project\obj\Release\130\android\assets\log4net.dll' because it is being used by another process. at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost) at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share) at Mono.Cecil.ModuleDefinition.Write(String fileName, WriterParameters parameters) in /Users/builder/jenkins/workspace/archive-mono/2020-02/android/release/external/cecil/Mono.Cecil/ModuleDefinition.cs:line 1160 at Mono.Linker.Steps.OutputStep.WriteAssembly(AssemblyDefinition assembly, String directory, WriterParameters writerParameters) --- End of inner exception stack trace --- at Mono.Linker.Steps.OutputStep.WriteAssembly(AssemblyDefinition assembly, String directory, WriterParameters writerParameters) at Mono.Linker.Steps.OutputStep.OutputAssembly(AssemblyDefinition assembly) at Mono.Linker.Steps.BaseStep.Process(LinkContext context) at Mono.Linker.Pipeline.ProcessStep(LinkContext context, IStep step) at Mono.Linker.Pipeline.Process(LinkContext context) at MonoDroid.Tuner.Linker.Process(LinkerOptions options, ILogger logger, LinkContext& context) at Xamarin.Android.Tasks.LinkAssemblies.Execute(DirectoryAssemblyResolver res) at Xamarin.Android.Tasks.LinkAssemblies.RunTask() at Microsoft.Android.Build.Tasks.AndroidTask.Execute() in /Users/runner/work/1/s/xamarin-android/external/xamarin-android-tools/src/Microsoft.Android.Build.BaseTasks/AndroidTask.cs:line 17 Lexacom.Mahon.Xamarin.Android

Any help or clarification of what is going wrong would be appreciated.

Beta nuget packages have a version appendage, eg -r1, or the more descriptive -{datestamp}-{commit_sha}; zarro already supports generating packages in this format, so actually producing the artifact shouldn't be that hard. However, the artifact should also be pushed to a repository somewhere - either to nuget (least surprise for users) or GitHub (to keep them separate from official releases, if that's even a desirable thing).

Ideally, we should produce a beta package any time code is pushed to GitHub in this repo so that it can be tested in consuming projects - and hopefully if we're making changes to resolve issues, we could point a user at a beta package to verify that the issue has indeed been resolved.

[Disclaimer: I am not a .NET developer. Apologies in advance if I say something nonsense.]

Currently, in the Log4Net website, I am not able to quickly answer the following questions:

• Is Log4Net available in NuGet? If so, what are its package coordinates?
• How can I quickly write a .NET application using Log4Net NuGet packages?

I suggest to update the current website as follows:

• Create an Installation page addressing the above questions to quickly get users started
• Create a Download page (currently the Download link in the left menu points to the Logging Services Download page), similar to the one Log4j has, containing two bullets:
  • "Do you want to install Log4Net in your .NET application? See the Installation page."
  • "Do you want to manually download the artifacts? See the Logging Services download page."

Provide the following convenience for PMC members to review the project:

git checkout <release-tag>
docker build -t log4net-builder .
docker run log4net-builder

That is, a convenience to
build a Docker image containing all necessary dependencies to be able to build the project
an entry point to build the project using the created Docker image.

Proposed by @vy