This is a general call-to-arms for everyone who uses log4net as their logging solution. If log4net is the logging framework that you are using and would like to keep using in the future it is time now to get involved. The project needs a larger developing community to move on! We really need more people who want to shape the future of log4net at the Apache Software Foundation.
In all the time since log4net has been started by Nicko Cadell more than ten years ago, there have never been more than two or three people regularly contributing to it. As is normal in open source projects people have come and gone when their interests or just the amount of time they could invest have changed.
At the moment Dominik Psenner and Stefan Bodewig are the only people semi-actively working on log4net and neither of them is able to devote as much time to the project as they'd like to and as would be required.
Realistically log4net is maintenance mode where development of new features is not going to happen.
This has repeatedly made log4net lag behind recent developments in the .NET world. It took a long time to get a version out that properly worked with .NET 4.0 in 2011 and adaptions to .NET 4.5 also took much longer than many users would have wished. We are seeing it again with .NET Core right now. In addition there are many unresolved issues in log4net's JIRA.
Despite this there are more than 2500 downloads of the logging framework every day from nuget. We are asking you, the log4net community, to get your hands dirty.
Right now we are in the process of creating a log4net release that works for .NET Core. It is a very targeted effort and it is very unlikely Dominik and Stefan will be able to contribute more in the future than we did during the past months.
If you are willing to help, please join log4net's dev mailing list and raise your hand. Look through log4net's issue tracker and pick things you'd like to work on. If you don't know where to start, please ask, Dominik and Stefan will be there to help.
If there is anything holding you back from contributing, let's discuss it and get it out of the way. Nothing is carved into stone, neither what the future of log4net holds nor how we make it happen.
Links
- log4net's JIRA
- https://issues.apache.org/jira/browse/LOG4NET
- dev mailing list
- https://logging.apache.org/log4net/mail-lists.html
- How the ASF works
- https://www.apache.org/foundation/how-it-works.html, https://www.apache.org/dev/contributors.html
path: /en/Apache/Log4Net | #
The last log4net release already stopped supporting Compact Framework 1.x and the Shared Source CLI as part of the binary distributions - but versions for them are still buildable from source. In order to figure out what platforms we will need to support in future releases the team is asking log4net's users to participate in a small survey.
Rather than repeating Roy's whole mail, here is the original announcement.
path: /en/Apache/Log4Net | #
As the release manager of this baby I'm happy it is done, the final steps took longer than I anticipated. As a user of log4net I'd say it was about time. Almost exactly five and a half years after the 1.2.10 release Apache log4net has a new release with lots of bug fixes a few new features - and support for .NET 4.0 as well as the Client Profiles of 3.5 and 4.0.
See the release notes for all the details, download 1.2.11 (remember to unblock the ZIP), tell us if anything doesn't work and join the community.
path: /en/Apache/Log4Net | #
About a month ago I've been elected as a committer to Apache log4net. Right now we are steadily working on getting a new release out - the first one in more than five years and even the first non-Incubator Apache release.
log4net's trunk has been holding quite a few bug-fixes and improvements for years now. In addition the .NET assemblies of the binary distribution reference the System.Web assembly and are not suitable for the newish 3.5 and 4.0 Client Profiles. This has been addressed in trunk and we will also provide an assembly targeting 4.0 proper.
The biggest hurdle for the release ironically has become support for the really old stuff. Here I'm putting together a few notes that will help me remebering what I did if I ever need to rebuild the environment - or others if they ever want to build a full log4net release.
Getting NAnt 0.91-alpha2 to work
In order to target .NET 4.0 the build process must use NAnt 0.91alpha2 - the latest release as of this writing. Actually this works well once you've pressed the correct button.
Initially I downloaded the ZIP, extracted it, ran it and was faced by an exception. The NAnt issue tracker is full of reports on this, one example is Issue 3048200. Fortunately I found the solution by searching around for a while. The assemblies of the ZIP downladed are blocked by Windows because the original ZIP originated from a different machine. The fix is to either unblock them all individually or - better - unblock the ZIP you've just downloaded before extracting NAnt.
Getting all supported platforms to build
The goal for the 1.2.11 release is to add support for .NET 3.5 Client Profile, .NET 4.0 and .NET 4.0 Client Profile while keeping suppport for all platforms supported by 1.2.10. After the release we intend to poll the user base to see what we can safely drop.
The Mono 2.4 that is installed on my Ubuntu 10.4 machine provides both Mono 1.0 and 2.0 in NAnt and I plan to mix the results with the rest built on a Windows box. I played with using Mono 2.10 on Windows but first it didn't provide Mono 1.0 and second it seems to have become more picky WRT XML comments and thus compilation fails - something I intend to address post-release.
You can download .NET frameworks 1.1 to 4.0 from MSDN, runtimes as well as SDKs. Initially I installed the SDK for 3.5SP1 in order to get support for .NET 2.0 and skipped 2.0 entirely. Later I learned that the SDK for .NET 2.0 also provides the necessary SDK for Compact Framework 2.0 - this is not true for the SDK of .NET 3.5 - so I installed the 2.0 version as well.
You can no longer download .NET 1.0 but it has been a free download at one point in time and it is still possible to get access to it if you are a MSDN subscriber. A kind soul who still had a 1.0 SDK provided me with it, thanks! Note that .NET 1.0 will not install if any other version of the .NET framework is installed, so install that first.
The .NET 1.0 SDK also provides the NAnt build target for what log4net calls CLI compatible so this is now covered as well.
The only things I can not build at this point in time is Compact Framework 1.0 and the assembly for the Shared Source CLI (also known as Rotor). I've found a download for SSCLI 1.0 - the Wikipedia page links to http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=14124 which still works, even though the page is not found if you search for SSCLI on MSDN. Unfortunately the release is source only and requires Visual C++ to build. It seems as if in order to build for Compact Framework 1.0 I'd need to install Visual Studio 2003 or even older.
Right now I'm not convinced that we won't just skip the two platforms and wait for people to complain.
Making it work on .NET 4.0
Making log4net build on .NET 4.0 was pretty easy once NAnt
0.91alpha2 worked. log4net is set up to treat warnings as errors so a
few obsolete (deprecated in Java lingo) method calls needed to be
guarded by #if !NET_4_0 blocks and replaced by their new
equivalents when building for 4.0. Unfortunately some rules have
changed and just because your assembly builds doesn't mean it will
work when you use it. As soon as you tried to log anything in a 4.0
application, a TypeInitializationException was
thrown.
.NET 4.0 has replaced the CAS security model with something that looks simpler on the surface. Basically it divides your code into "security critical", "security safe critical" and "transparent" code where "security critical" code must not be called from "transparent" code and is the only code allowed to perform - you guessed it - "security critical" operations.
The TypeLoadException occurs as ISerializable's
GetObjectData is now marked as "security critical" and
all implementing classes are supposed to be marked as such as well.
They must no longer be marked with a
SecurityPermissionAttribute requesting a
SerializationFormatter as it used to be best practice in previous
versions of the framework. This doesn't cause any problem during
compilation but results in an exception at runtime.
There've been several similar places where we needed to add
SecuritySafeCritical attributes for file access or code
using P/Invoke. I found the best way to identify those potential
problems was by running Visual Studion 2010's static code analysis
using the "Microsoft Security Rules". At least in the code covered by
our test cases we seem to have fixed all issues.
path: /en/Apache/Log4Net | #
has been released, something that a lot of people I know (including my team at work) have been waiting for.
This (at least partly) addresses the second of two points Loren Halvorson had in favor of the Microsoft Enterprise Logging Block.
path: /en/Apache/Log4Net | #