Log4Net problem?

[Former Member]

We are using the crystal runtime (v13 SP1 x86) in some of our dlls. We are developing on Win 7 x64. All our apps are compiled under x86. We are using the .Net Framework 4.0

Recently we wanted to add log4net to our Data Tier DLL (version 1.12.11) which works and compiles fine. Any time you compile any project that uses our data tier dll you get the following warning:

No way to resolve conflict between "log4net, Version=1.2.11.0, Culture=neutral, PublicKeyToken=669e0ddf0bb1aa2a" and "log4net, Version=1.2.10.0, Culture=neutral, PublicKeyToken=692fbea5521e1304". Choosing "log4net, Version=1.2.11.0, Culture=neutral, PublicKeyToken=669e0ddf0bb1aa2a" arbitrarily.

Please note everything still compiles just fine its just we get the warning above.

We having been dealing with this problem for awhile and have spent a lot of time trying to resolve it. I currently have a support case open with microsoft and really i don't think they have gave me any solid answers yet.

Crystal Runtime installs log4net into the .net 2.0 GAC (%windir%\assembly).

I had the understanding that you couldn't load a .net framework 2.0 dll from a .net 4.0 project but it looks like that is incorrect. It looks like .net 4.0 has the ability to load .net 2.0 framework dlls (via the CLR hosting api).

If i specifically remove the log4net (1.2.10) that crystal installed then the error goes away.

I have tried all of the following:

1. Put the log4net 1.2.11 (.net 4.0) in the GAC

2. Set the reference to log4net in our data dll to Specific Version = TRUE

3. Tried to add an reference hint (HintPath) to a specfic location (before we added log4net to the GAC)

At first Microsoft recommended doing reflection but we won't do that. We call log4net to much and using reflection for that many calls is UGLY and it would slow things way down.  They want us to now look into policy redirection which we i still need to do to see if its a workable solution.

So my questions are:

1. is there a way to get around this problem?

2. Can anyone delve into why the problems happening?

If there isn't anyway to get around this problem it seems to be a gaping hole in how SAP decided to address this. log4net is a very frequently used logging library and to make the decision to use it even when everyone who used your product seems to be a very bad decision. Maybe even they were going to use log4net they should have least built from source and renamed the dll.

[daniel_paulsen · Accepted solution]

I'm not sure if this will solve the issue, but can you try the following?

navigate to:

C:\Windows\Microsoft.NET\Framework\v4.0.30319\RedistList

and edit the VSList.xml file.

Add the following to the file list:

<File AssemblyName="log4net", Version="1.2.11.0", PublicKeyToken="669e0ddf0bb1aa2a", Culture="neutral", ProcessorArchitecture="x86" InGAC="true" />

and set

Specific Version = True for this assembly in your Data Tier dll.

[former_member183750]

Hello Brent

Wondering if the suggestion posted by Dan helped?

- Ludek

[Former Member]

Can't speak for Dan, but when I tried it, Acess was denied.  Next!