October 6, 2010 .NET, Deployment
October 6, 2010 .NET, Deployment
So few days ago I faced with issue of 3rd party references.
My original question on stackoverflow:
What is the best approach to use 3rd party that uses another version of other 3rd party (log4net) already used in the system?
I got (as for now) two answers and I would like to try them out.
So I created 3 projects, one references log4net of version of 1.2.10.0 and another references 1.2.9.0. Both of them are referenced in client console application, which also references one of the log4net assemblies. In client application I’m trying to execute code that requires log4net in both of the assemblies.
Below is projects layout:
When I execute my code I’m getting error:
In order to resolve this I tried suggestion one by one…
Suggestion number 1
Accordingly to MSDN there is possibility to redirect code execution to assembly with higher version, just with using following configuration:
<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>
I’ve tried it and it did not work. Reason is that we cannot do redirection between assemblies with different PublicKeyToken-s. log4net 1.2.9.0 has “b32731d11ce58905” and log4net 1.2.10.0 has “1b44e1d426115821”. Also see this stackoverflow question.
Suggestion number 2
Use GAC. So when I install those two assemblies into GAC:
In this case code works, but suggestion doesn’t work for us, since we do not want to gac assemblies we use.
Other suggestions
So I’ve been thinking about another approach.
Approaches that require rebuilding our code with different version of log4net are not suitable for us. At least for now.
Another thing about which I’ve been thinking is to load those assemblies into different application domain or host 3rd party that uses 1.2.9.0 under different WinService. Both of these are cumbersome solutions and I like to avoid them.
YOUR SUGGESTION
If you have some ideas, could you please let me know!
[EDITED 7 Oct, 2010 11PM]
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! :)
Markdown | Result |
---|---|
*text* | text |
**text** | text |
***text*** | text |
`code` | code |
~~~ more code ~~~~ |
more code |
[Link](https://www.example.com) | Link |
* Listitem |
|
> Quote | Quote |
You can try to set Private path for your application and use your subdirectory for required assemblies. http://msdn.microsoft.com/en-us/library/823z9h8w.aspx
In process of trying this out… thanks…
So, I had some hopes that this will help, but it did not.
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 log4net and it doesn't match required one.
Even more 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.
Switching to:
< probing privatePath = "log4net1210;log4net129;" / >
changes situation vise verse.
All depends on which version I demand first :)
Very funny!
Have you tried to post this on Stackoverflow?
Or take a look here http://stackoverflow.com/questions/1460271/how-to-use-assembly-binding-redirection-to-ignore-revision-and-build-numbers/2344624#2344624, but it is not an _easy_ solution.
Man, were you attentive when reading this blog post? :)
It started with "My original question on stackoverflow:
What is the best approach to use 3rd party that uses another version of other 3rd party (log4net) already used in the system?"
By that link they are loading assembly into different application domain. I said that this is cumbersome solution, but it should work of course.
take a look at a freshly new NuPack, announced day or two earlier. It's package management system (open-source) for VS10. I don't know exactly, but it should solve your problem with dependencies
How about loading the older version into a custom AppDomain?
I would suggest that you should play with AppDomains a bit – looks like a typical class loader issue for me :)
Таke a look at these events that AppDomain type exposes: AssemblyLoad, AssemblyResolve, TypeResolve
Oleh, I already mentioned that we do not want to overplay with such custom things like separate AppDomain to load assemblies to.
uh, right – I missed your comment. But I think it is your only viable solution
All, just read this edit added at the bottom of post:
FUNNY-HAPPY-END OF THIS STORY