how do I work around log4net keeping changing publickeytoken

Asked 5/1, 2012 at 14:19 Answered 28/5, 2015 at 22:22

104

We have an asp.net 4.0 project which uses a couple of frameworks which is dependent on log4net version 1.2.10.0. Today I tried to include a new framework which is dependent on log4net version 1.2.11.0, I've been stuck ever since:

log4net 1.2.10.0 has publickeytoken = 1b44e1d426115821

log4net 1.2.11.0 has publickeytoken = 669e0ddf0bb1aa2a

Since these are different i cannot use either assembly redirects (to make all frameworks use the same version of log4net) or codebase (to have just the new framework use version 1.2.11.0) through the runtime element in web.config.

What are my options here ?

(and why the bleep does log4net keep changing publickeytokens between versions, as I understand it a lost key was the reason for the switch between version 1.2.9.0 and 1.2.10.0, did they lose the key yet again? I'll volunteer my dropbox to keep it safe if they need it...)

Edit: Ok, so the log4net guys apparently had the idea that releasing with two keys was a good idea, but that means that every framework you make use of needs to agree on which of the two flavors they prefer, or those frameworks cannot work side by side in the same appdomain. Am I the only one finding this a horrible idea? if everyone did this then everything would break down, right?

Edit2: As I stated, I'm not using log4net in my business code, but I use several frameworks which depend on 1.2.10.0, and the problem arose when I tried to use a new framework which depended on 1.2.11.0 (new key), so Stefans answer doesn't apply, because the new framework will expect the new key, not the old one

Mazzard answered 5/1, 2012 at 14:19 Comment(2)

IMHO, the first error from apache here is to provide the binaries signed with new key : the new key is intended for patched/enhanced open source version and shouldn't be used as is. The second error is that the framework you are speaking about has been released with the new log4net signature only : a version with the old signature should exist. – Meuser 12/1, 2012 at 8:5

Actually, you're looking at the third flavor: the one the geniuses at SAP recompiled with their own strong name, as part of the Crystal Reports for Visual Studio package, and to make matters worse, they stuck it in the GAC which will make your dependencies across machines a nightmare. – Evelinaeveline 22/8, 2012 at 20:23

This is how I got things working with version 1.2.11.0.

Curse apache for changing the key in the first place :)
Download the version of 1.2.11.0 signed with the old key.
Sort out your own code out by removing any direct references to log4net (new key) and replace with a reference to the assembly signed with the old key.
Sort out any dependant assemblies you may have by including this segment in your web/app.config

   <runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
            <dependentAssembly>
                <assemblyIdentity name="log4net" publicKeyToken="1b44e1d426115821" culture="neutral" />
                <bindingRedirect oldVersion="0.0.0.0-1.2.10.0"
                                 newVersion="1.2.11.0"/>
            </dependentAssembly>
        </assemblyBinding>
    </runtime>

Eldridgeeldritch answered 10/1, 2012 at 16:22 Comment(9)

Downloading the version signed with the old public key is necessary as unfortunately it is not possible to perform a binding redirect to an assembly with a different public key. – Eldridgeeldritch 10/1, 2012 at 16:24

This seems to fail due to a breaking change in 1.2.11.0: netpl.blogspot.com/2012/03/… – Electropositive 5/12, 2012 at 18:58

Has anyone found a solution to the problems described at the link mentioned by @Electropositive which causes the following exception: Method not found: 'Void log4net.Config.BasicConfigurator.Configure()' – Hatchel 12/2, 2013 at 19:52

There is no solution other than downgrading to 1.2.10, unfortunately. (or recompiling every dependent assembly you use). – Equilibrium 5/9, 2013 at 21:56

@Hatchel you HAVE to use the 1.2.10 version for the 1.2.10 dependencies you cant use the 1.2.11 because it's missing the .Configure() method. 1.2.10 can still be downloaded here: file:///C:/Users/danielpupek/Downloads/incubating-log4net-1.2.10.zip Just reference 1.2.11 like normal and use the above instructions to point to 1.2.10 – Hebetude 10/10, 2013 at 21:48

Put the 1.2.10 assembly in a different directory and use this config: '<dependentAssembly> <assemblyIdentity name="log4net" publicKeyToken="1b44e1d426115821" culture="neutral"/> <bindingRedirect oldVersion="0.0.0.0-1.2.9.0" newVersion="1.2.10.0"/> <codeBase version="1.2.10.0" href="Resources\log4net-oldkey\log4net.dll" /> </dependentAssembly>' – Hebetude 10/10, 2013 at 21:50

@AgileJedi - I have tried the post you refer to and I can confirm that this works for me. – Amphipod 31/10, 2013 at 14:8

using a third party library so don't have the luxury to rebind it to the one with old key.. this is a disaster. – Panier 12/2, 2015 at 21:16

Download link no longer works :( I mean how stupid can they be? – Northumbria 3/9, 2018 at 21:35

I am using the latest version of log4net which I downloaded through nuget. However, one of the libraries that I'm using requires the old version. My troubles led me to this question.

The problem with the other answers are that they are using the same dll version for all bindings. I want to use features in the new version for everything else but the legacy dependency.

To be able to do that you need to do the following:

Start by downloading the old version (version of 1.2.11.0).
Rename the downloaded binary to log4net.1.2.10.dll. Include it in your startup project with Build action set to None and "Copy if newer"
Tell .NET where it can find the old version:

App.config

<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <dependentAssembly>
            <assemblyIdentity name="log4net" publicKeyToken="1b44e1d426115821" />
            <codeBase version="1.2.10.0" href="log4net.1.2.10.dll" />
        </dependentAssembly>
    </assemblyBinding>
</runtime>

The href attributes identifies where the old version is. Hence all other requests for log4net will point on the new version.

Auric answered 13/11, 2014 at 13:13 Comment(2)

This is a great solution because it allows you to maintain both versions for libraries that reference either. – Waist 4/2, 2015 at 15:59

THANK YOU! This saved me. I had to change the "Copy to output directory" to "Do not copy", but otherwise it worked like a charm! – Shoal 18/5, 2018 at 15:24

You can download a version of log4net 1.2.11.0 that is signed with the old key. The reason why the changed to a new key is explained in their FAQ:

http://logging.apache.org/log4net/release/faq.html#two-snks

(Basically the new key is publicly available and for some reason they did not want to include the old key in the distribution. It is not clear to me why they did not just make the old key publicly available though)

Footton answered 6/1, 2012 at 9:15 Comment(4)

But when I use a third party library which is tied to the new key, I'm still stuck (right?). It's not my choice to use the new log4net, it's the third party framework. I can't see how this stuff isn't going to blow up in everyones face as more and more frameworks starts to use log4net with the new key – Mazzard 6/1, 2012 at 9:58

That is unfortunately correct. I guess you need to consider not having all components use the same version of log4net... – Footton 6/1, 2012 at 10:51

.... and how would I go about doing that? Is there any mechanism in .net for handling this issue? – Mazzard 6/1, 2012 at 12:20

Yes, there is: #3159428 – Hardesty 27/12, 2012 at 18:17

Don't know is it suitable for your particular case or not, but you can recompile one of the frameworks, so they will use log4net with the same public key. In my case it was FluentNHibernate which uses log4net 1.2.10 and Combres with log4net 1.2.11 with new key. I downloaded log4net 1.2.11 signed with old key and recompiled Combress with it. After that added assembly binding redirect from 1.2.10 to 1.2.11 and it starts working.

Coryphaeus answered 14/5, 2012 at 21:24 Comment(0)

This won't necessarily work in all cases, but because the project that was using log4net was OSS I downloaded the source, replaced the conflicting version of log4net with the version I was using and rebuilt the project. In my case it was Topshelf, so I now have a version of the Topshelf assembly that was built with the same version of log4net I'm using and now I can reference both without a problem.

Neile answered 21/1, 2012 at 15:59 Comment(0)

I tried to go to the links provided above, but it seems like all the links in the Apache site are not working. Then this is what I did to resolve the issue:

From your Visual Studio, use Nuget to download and install the latest version of log4net (1.2.13.0). The NuGet package manager will automatically download and upgrade all the log4net(1.2.11.0) to the latest version.

Groenendael answered 28/5, 2015 at 22:22 Comment(0)

Recommended topics

Hot tags