Log4Net has proven to be a bit of a pain in the neck for a lot of framework developers (including Microsoft even!). When we upgraded to 1.2.11, we 'fixed' the version so that we wouldn't be caught out if the authors of Log4Net do the same thing
again.

My guess is that NServiceBus may have done the same thing, but chose to stick with 1.2.10 - making them incompatible. Not sure what I can recommend to resolve this one

"I assume NOF specifically requires the version of log4net 1.2.11 that has been signed with the new public key?"

Yes. That was the problem: the log4net guys changed the public key (for no good reason - other packaged framework providers don't do this so far as I know). We probably could have stuck with 1.2.10 (we don't need any of
the new features) - but then we would only face the problem in reverse if you wanted to reference another framework that had gone with the new key!

We perhaps need to seriously consider other options, such as moving to a different logging framework - but that's not something we can do in a hurry.

"I assume NOF specifically requires the version of log4net 1.2.11 that has been signed with the new public key?"

Yes. That was the problem: the log4net guys changed the public key (for no good reason - other packaged framework providers don't do this so far as I know). We probably could have stuck with 1.2.10 (we don't need any of the new features) - but then we would
only face the problem in reverse if you wanted to reference another framework that had gone with the new key!

We perhaps need to seriously consider other options, such as moving to a different logging framework - but that's not something we can do in a hurry.

The long term fix is for us to decouple Naked Objects from log4Net, by defining our own logging wrapper. FYI Stef advises me that ha had already done this within the Restful Objects code - because we were forced to. (FYI, Dan, this was because of the
need to create two versions of the 'surface': one for NOF2 and one for NOF4, which use different versions of log4net). And we can then easily provide two implementations of this logging wrapper, for the two 'keyed' versions of log4net.) Changing
between these will be as simple as editing the packages.config file in your solution - NuGet will look after the rest. (This would also make it easier for a user to switch to a different logging framework).

I'll raise a ticket for that shortly - and will prioritise it for the next release, but we don't have a timetable for that yet. The earliest will probably be a month from now, the latest by the year-end - please don't push
me for a date as there isn't one. (N.B. This is not a hard change, but it is not trivial either).

In the short-term, Jacques, the fix is for you to re-compile the framework using the version of log4net that you want. This is not hard to do: it just involves configuration, not any code change.