102

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

AndreasKnudsen
  • 3,453
  • 5
  • 28
  • 33
  • 1
    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. – JoeBilly Jan 12 '12 at 08:05
  • 6
    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. – Jeremy Holovacs Aug 22 '12 at 20:23

6 Answers6

65

This is how I got things working with version 1.2.11.0.

  1. Curse apache for changing the key in the first place :)
  2. Download the version of 1.2.11.0 signed with the old key.
  3. 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.
  4. 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>
gsk
  • 1,233
  • 15
  • 32
David Christiansen
  • 5,869
  • 2
  • 36
  • 42
  • 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. – David Christiansen Jan 10 '12 at 16:24
  • 2
    This seems to fail due to a breaking change in 1.2.11.0: http://netpl.blogspot.com/2012/03/pathetic-breaking-change-between.html – sydneyos Dec 05 '12 at 18:58
  • Has anyone found a solution to the problems described at the link mentioned by @sydneyos which causes the following exception: `Method not found: 'Void log4net.Config.BasicConfigurator.Configure()'` – Neo Feb 12 '13 at 19:52
  • There is no solution other than downgrading to 1.2.10, unfortunately. (or recompiling every dependent assembly you use). – bk0 Sep 05 '13 at 21:56
  • @Neo 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 – Agile Jedi Oct 10 '13 at 21:48
  • 1
    Put the 1.2.10 assembly in a different directory and use this config: ' ' – Agile Jedi Oct 10 '13 at 21:50
  • @AgileJedi - I have tried the post you refer to and I can confirm that this works for me. – ctrlplusb Oct 31 '13 at 14:08
  • using a third party library so don't have the luxury to rebind it to the one with old key.. this is a disaster. – Sonic Soul Feb 12 '15 at 21:16
  • Download link no longer works :( I mean how stupid can they be? – alamar Sep 03 '18 at 21:35
30

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:

  1. Start by downloading the old version (version of 1.2.11.0).
  2. 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" enter image description here
  3. 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.

jgauffin
  • 99,844
  • 45
  • 235
  • 372
3

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)

Stefan Egli
  • 17,398
  • 3
  • 54
  • 75
  • 10
    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 – AndreasKnudsen Jan 06 '12 at 09:58
  • That is unfortunately correct. I guess you need to consider not having all components use the same version of log4net... – Stefan Egli Jan 06 '12 at 10:51
  • 1
    .... and how would I go about doing that? Is there any mechanism in .net for handling this issue? – AndreasKnudsen Jan 06 '12 at 12:20
  • Yes, there is: http://stackoverflow.com/questions/3158928/referencing-2-differents-versions-of-log4net-in-the-same-solution – ms007 Dec 27 '12 at 18:17
1

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.

alex
  • 187
  • 1
  • 9
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.

George Huang
  • 2,504
  • 5
  • 25
  • 47
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.

Mark J Miller
  • 4,751
  • 5
  • 44
  • 74