I spent large chunks of July and August working on Zip64 support for the ZIP package of Commons Compress and think it is in a state where we can have more people test it. It needs some interop tests against PKZip (dont have access to it myself) and I may need to document the known interop problems with OpenJDK7, but that's it.
As a side effect of the Zip64 stuff (which enables Compress to deal
with archives and entries > 4GB or with more than 64K entries)
Commons Compress 1.3 will require Java5 as I thought we'd
need Deflater#getBytesRead but it turned out this
method does not return the actual number of bytes read but the
number modulo 2^32 (it seems to be an unsigned int that's wrapping
around) - at least for Java5 and 6, OpenJDK7 seems to be OK.
Given that Java5 was not strictly necessary I may even think about backporting the stuff to Ant's zip package.
Then Compress' trunk contains read-only support for the Unix dump format due to Bear Giles and support for Pack200 compression. It may even get support for XZ compression based on XZ for Java due to Lasse Collin - if we can find an easy way to integrate it.
path: /en/Apache/Commons | #
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 | #