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.

unblock

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

Ant releases have become more frequent than my blog posts by now, oh my. I won't promise anything.

While most of the world was on vacation Antoine (again) put together a new relase of Apache Ant and announced 1.8.2 late December. As usual a full list of fixed issues can be found in Bugzilla. This time it not only contains bug fixes (quite a few of them, though) but also some new features like improved support for Apache Harmony, gcj and OpenJDK7 (where javac likes to break command line backwards compatibility again).

The issues that came up most frequently and have been fixed are "xslt no longer uses the specified classpath" and "propertyfile with prefix doesn't work as expected" IIRC.

We've added a new collection so that the order of files inside <copy> has become predictable. Detecting Ant 1.8.2 means either

  <antversion property="Ant-1.8.2-or-later"
              atleast="1.8.2"/>

or

  <available property="Ant-1.8.2-or-later"
             classname="org.apache.tools.ant.util.LinkedHashtable"/>

path: /en/Apache/Ant | #

Last weekend Antoine announced Ant 1.8.1. This is more or less a pure bugfix release which addresses a few important issues. The fix with the biggest impact likely is that <extension-point> and <import> finally work together as intended - and even documented.

The full list of issues raised against Ant that have been fixed with this release can be found in Bugzilla. We've adressed almost all issues raised against Ant 1.8.0 so far.

Thanks to the new <augment> task, detecting Ant 1.8.1 means either

  <antversion property="Ant-1.8.1-or-later"
              atleast="1.8.1"/>

or

  <available property="Ant-1.8.1-or-later"
             classname="org.apache.tools.ant.taskdefs.AugmentReference"/>

path: /en/Apache/Ant | #

So Apache Ant 1.8.0 is out and I'm supposed to follow a tradition I started with Ant 1.6.2. If you can be sure that you are at least using Ant 1.7.0 then the built-in <antversion> task/condition will do:

  <antversion property="Ant-1.8.0-or-later"
              atleast="1.8.0"/>

otherwise the trick of checking for a class that has been introduced with Ant 1.8.0 can always be used:

  <available property="Ant-1.8.0-or-later"
             classname="org.apache.tools.ant.types.resources.MappedResource"/>

path: /en/Apache/Ant | #

Antoine Levy-Lambert has recently built the first release candidate for Ant 1.8.0 and called for a vote, so we should be close to the first Ant release since eighteen months. This release mostly brings enhancements and bug fixes to many tasks and types (this is the real strength of Ant IMHO) but there also are a few core changes, the full list is here.

My personal top five changes (I know there are six items, but the first one doesn't count ;-):

extension-point and some changes in import and its new cousin include have been inspired by Easyant which can now use an un-patched version of Ant together with a custom ProjectHelper to create a build system quite different from Ant's original ideas. ProjectHelper is the mechanism that allowed me to sketch JavaFront or Nicolas Lalevée to write GroovyFront which lets you write build files in Groovy.

path: /en/Apache/Ant | #