Home/ Questions/Q 7842529
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-02T16:20:40+00:00

Recently added log4net.dll to our data object. Our data object builds perfectly but when

  • 0

Recently added log4net.dll to our data object. Our data object builds perfectly but when you try to build anything that references our data object you get the following error:

No way to resolve conflict between “log4net, Version=1.2.10.0, Culture=neutral, PublicKeyToken=692fbea5521e1304” and “log4net, Version=1.2.9.0, Culture=neutral, PublicKeyToken=b32731d11ce58905”. Choosing “log4net, Version=1.2.10.0, Culture=neutral, PublicKeyToken=692fbea5521e1304” arbitrarily.

I found the following thread that enabled me to get more information about the problem.

log4net is used for a variety of things in our project. For example, crystal installed 1.2.9 into the GAC. I know infragictics uses 1.2.10.

We have a specific directory – call it c:\references – where we build all our dlls to and that all our applications use to reference our internal dlls. So I specifically set my reference in our data object to c:\references\log4net.dll which is version 1.2.11. Which is weird because in the error message above you don’t see 1.2.11. The dll is referenced with specific version: = True & Copy Local:= True. I checked the build directory & 1.2.11 of log4net did get moved correctly.

If it helps here are some of the detailed error messages: 

There was a conflict between "log4net, Version=1.2.10.0, Culture=neutral, PublicKeyToken=692fbea5521e1304" and "log4net, Version=1.2.9.0, Culture=neutral, PublicKeyToken=b32731d11ce58905".
  No way to resolve conflict between "log4net, Version=1.2.10.0, Culture=neutral, PublicKeyToken=692fbea5521e1304" and "log4net, Version=1.2.9.0, Culture=neutral, PublicKeyToken=b32731d11ce58905". Choosing "log4net, Version=1.2.10.0, Culture=neutral, PublicKeyToken=692fbea5521e1304" arbitrarily.
      References which depend on "log4net, Version=1.2.10.0, Culture=neutral, PublicKeyToken=692fbea5521e1304" [C:\Windows\assembly\GAC_32\log4net\1.2.10.0__692fbea5521e1304\log4net.dll].
          C:\Windows\assembly\GAC_MSIL\CrystalDecisions.Shared\13.0.2000.0__692fbea5521e1304\CrystalDecisions.Shared.dll

   References which depend on "log4net, Version=1.2.9.0, Culture=neutral, PublicKeyToken=b32731d11ce58905" [C:\Program Files (x86)\Business Objects\Common\4.0\managed\log4net.dll].          c:\references\DBObjectAdoNet.dll
            Project file item includes which caused reference "c:\references\DBObjectAdoNet.dll".

Update: So far the only way I found to fix the error is to reference log4net in anything referencing DBObjectAdoNet.dll. This isn’t really a usable solution for us since almost
everything in our entire system uses it.

2nd Update: Tried putting log4net in the GAC thinking that would fix the problem but still no go.

3rd Update: I’ve made a support call to Microsoft. They want me to use Assembly.LoadFrom() which I’m very, very hesitant to do since we make over 300,000 calls in one application and would require reflection for each call which would slow things down quite a bit.

I found out if I uninstall the crystal runtime on my machine the error goes away which doesn’t make a lot of sense because the only thing it does, as far as I can tell, is remove log4net 1.2.10.0 from the GAC under the .NET framework 2.0 folders, which shouldn’t matter because the app is a .NET framework 4 app.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    We found out that crystal runtime was definitely the problem. If we uninstall log4net at %windir%\assembly that crystal runtime installed then the warning message goes away. What’s weird is that if I install log4net 1.2.10 from log4net’s site into the GAC then the warning message doesn’t reappear. If anyone can explain that then please add to this thread. Crystal signed log4net with their own strong name key (the public key token is different).

    The key to fixing the log4net problem is that log4net is a open source project. Which means we can simply build the dll from source with a different name. Haven’t tried it out yet but that should fix the problem. We’ll have the extra step of building from source every time we want to update log4net but considering how much we are going to update the dll it isn’t a big deal.

    • 0