14

I've spent the last 2 hours looking over these issues on SO, and nothing seems to be working.

I have a solution that uses log4net 1.2.11, via NuGet. It works fine on my 32 bit development workstation running Windows 7. It does not run on my 64-bit Windows 2008 R2 test system. The error I get is:

Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly 'log4net, Version=1.2.11.0, Culture=neutral, PublicKeyToken=669e0ddf0bb1aa2a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.

I am looking in the application directory on my test system. The log4net.dll file there is version 1.2.11.

The version in the GAC was version 1.2.10. I have removed it. There was a version on my development server that was yet again something else; I removed that as well. I have rebuilt; I have redeployed. I have added 

<dependentAssembly>
    <assemblyIdentity name="log4net" publicKeyToken="669E0DDF0BB1AA2A" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-1.2.10.0" newVersion="1.2.11.0"/>
</dependentAssembly>

to my configuration file. Nothing seems to make a bit of difference. My deployment project shows the right version and signature of the log4net assembly that is being deployed.

I do not know what else I can do, but I am getting quite frustrated that a logging library is preventing my application from running.

What have I missed?

Uwe Keim
  • 39,551
  • 56
  • 175
  • 291
Jeremy Holovacs
  • 22,480
  • 33
  • 117
  • 254

4 Answers4

6

I had this issue after upgrading log4net through NuGet, only to find that the newer version was signed with a different key. Sigh. For some reason this only became apparent when I deployed to the live server, it didn't crop up in development.

You can grab the 'oldkey' version from the apache log4net site. Just nuke your references from the project file and reference the oldkey version instead.

keithl8041
  • 2,383
  • 20
  • 27
4

Here was my solution: I changed from log4net to Common.Logging to NLog. It didn't take a lot of effort, and I don't think it should have been necessary, but it worked, and worked well.

Jeremy Holovacs
  • 22,480
  • 33
  • 117
  • 254
  • I had to do the same thing. The problem is when dependencies require conflicting versions of log4net. – Jim Raden Dec 21 '12 at 02:41
  • 3
    See @keithl8041's answer for an actual solution to this problem rather than a work around. :) – Johny Skovdal Mar 14 '13 at 08:40
  • @JohnySkovdal, actually I would call that a workaround as well. That means you have to continue using a deprecated library and an old library key with a clear EOL. That limits your options in the future. – Jeremy Holovacs Apr 16 '13 at 12:34
  • @JeremyHolovacs Not the way I understand it. It's something to use until your other dependencies gets up to speed. For now, the latest version is available with both keys, so that solution only a uses deprecated key, not a deprecated library. – Johny Skovdal Apr 16 '13 at 19:33
  • 1
    @JohnySkovdal I think we're looking at it from different angles, but Common.Logging allowed me to completely ignore an extraordinarily poor design/ implementation decision by our friends at apache, without worrying about about waiting for everyone to catch up. This was a quick and painless alternative that circumvented the problem entirely. I have adopted this in all my applications now, and it just works. I highly recommend it. – Jeremy Holovacs Apr 16 '13 at 19:51
3

We are having the exact same issue. A dependency deep in the code base is putting 1.2.10 into the GAC and NuGet is trying to use 1.2.11. We gave up using NuGet for log4net, too much of a headache. Seems NuGet is a bit all or nothing.

Bart
  • 99
  • 1
  • 11
3

Sometimes you have to really drill down into the project dependencies. In my case it was a reference of a reference of the actual Service Stack project that was referencing a different version of Log4Net.

To fix it I added the newest version of Log4Net from nuget to the ServiceStack project. I also made sure the direct reference was using the newest version and this solved the issue.

You can use a dependency tool to quickly find which references are using conflicting versions, but if you don't have a tool for this you can just compile the project's reference by itself and see what version of log4net.dll gets copied to the directory.

Despertar
  • 21,627
  • 11
  • 81
  • 79