views:

79

answers:

2
  • Currently we use log4net of version 1.2.10.0 and we should start using some 3rd party components developed by other team.
  • Mentioned component references log4net of version 1.2.9.0.
  • All binaries are deployed into one folder.

I'm sure that we cannot rebuild our sources with 1.2.9.0 version, because there are too many other dependencies and will require lot of efforts. Are there any other approaches to solve this issue? I'm NOT looking for too sophisticated that have something to do with CLR assemblies loading, but would hear them with great pleasure. I'm looking for the simplest approaches. I guess someone has encountered the same issue.

EDITED: If someone got interested I created blog post on this: http://andriybuday.blogspot.com/2010/10/log4net-versions-deployment-issue.html

EDITED2: So, this edit is not answer, but it represents unexpected end of this story. I just copied it from blog post.

FUNNY-HAPPY-END OF THIS STORY

Do you know what is the most interesting about all of this? It is how it has finished. We contacted those guys, who developed component we now should use. They gave us know, that they were encountering issues with updating on-the-fly configuration file for log4net 1.2.10.0. By their words, new version of log4net is not capable of doing this. So they sent as simple application that demonstrates this, and indeed, after updating config when app is running, 1.2.10.0 did not catch up new configuration, but 1.2.9.0 was working just fine. This surprised me very much, so I went to this download page and downloaded latest binaries. When I tried it got working!!! Actually I guess that they simply used version of log4net buit with references to .net framework 1.1, and we should use one built with .net 2.0 (Yeah! Actually if you would download you will see.)

After all of this, they created new sub-release of their sources especially for us and they were able to fix some minor bug. Great news! Unexpected end of story! :)

+2  A: 

The recommended approach would be to install both versions of log4net into the Global Assembly Cache (GAC).

If however you can't change the requirement of loading all assemblies from a single folder, it is probably easiest to rename the copy of log4net used by your projects and reference the renamed version.

0xA3
Yeah, it makes sense. Will see if others have some different ideas. Thanks.
Andriy Buday
Having all in GAC helps, but indeed that is something we don't want to do.
Andriy Buday
Renaming one copy of the assembly also doesn't help.
Andriy Buday
Someone has suggested to use privatePath, but it also doesn't help. So .net allows me use private path and define two pathes to two assemblies but with different versions of log4net and it is loaded at runtime just fine, but when my code requires another version of log4net it doesn't load it, maybe because it thinks that it already has loaded.Ordering is taken into account, so if I have following:< probing privatePath="log4net129;log4net1210;" / >it will load version 1.2.9.0 and will NOT load 1.2.10.0, but will fail once I need it.All depends on which version I demand first :)Very funny!
Andriy Buday
Since GAC suggestion is something I like and it works, but still not sure to what decision my team will come I accept this answer. Thanks!
Andriy Buday
+2  A: 

I don't know what the changes are between the two versions (we use 1.2.10.0 ourselves) but if the interfaces have not changed then you could try an assembly redirect to the newer version:

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

Make sure that the key is the same as the one I provided as they may have changed between the two.

http://msdn.microsoft.com/en-us/library/7wd6ex19(VS.71).aspx

Bronumski
Cool, I did not know about this! You rock!
Andriy Buday
I'm actually not sure if you can do this now. If the keys are different between the two versions then it will not work.
Bronumski
I have to check this. I will post comment once will have results.
Andriy Buday
This approach doesn't work. Accordiongly to this http://stackoverflow.com/questions/2191296/net-assembly-binding-redirect-with-differing-public-key-tokens we cannot redirect between assemblies with different publicKeyToken. 1.2.10.0 has token "1b44e1d426115821" (sadly, but not equal to "b32731d11ce58905"). Also I'm still not sure if this will work outside of the GAC.
Andriy Buday