[
https://issues.apache.org/jira/browse/LOG4NET-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13789065#comment-13789065
]
Joe commented on LOG4NET-397:
-----------------------------
> "... if a third party library uses log4net and another third party library
> uses another version of log4net, then the dependencies have to be fixed in
> either or both of the third party libraries".
If I have the ability to fix the conflicting libraries, I can use a single
version of log4net and the problem doesn't arise. But the reality is that
third party libraries can't always be fixed, or at least not in a timely
manner.
> Deployment issues have to be addresses...
This is more than a deployment issue.
> I can see no way how we could fix problems others create by referencing/using
> log4net badly.
I don't see who is referencing log4net "badly". Supplier A used the old strong
name key, which was the only one available when he shipped his component.
Supplier B used the new strong name, which seems to be what is recommended
currently, and is what he'll get if he uses NuGet to obtain log4net.
The "fix" in my view is what I suggested: the "new key" version should have a
different filename, and you should consider shipping a special "old key"
version of log4net that uses Type forwarding to forward to the new version. In
this way components from both Supplier A and Supplier B can be included in an
application without conflict.
> Conflicts due to new strong name key
> ------------------------------------
>
> Key: LOG4NET-397
> URL: https://issues.apache.org/jira/browse/LOG4NET-397
> Project: Log4net
> Issue Type: Bug
> Reporter: Joe
>
> Consider an application that uses two third-party assemblies:
> - AssemblyA from Supplier A, compiled with log4net 1.2.10 (old strong-name
> key)
> - AssemblyB from Supplier B, compiled with log4net 1.2.11 (new strong-name
> key)
> How can I make these two assemblies co-exist and use the same version of
> log4net?
> Maybe I'm missing something obvious, but I can't see any way to do this: for
> example I obviously can't have both log4net assemblies in the same bin
> folder, as they have the same name.
> I'm obviously not the only one who thinks there's a problem, e.g. issue
> LOG4NET-324 refers to "... the strong name horror too". The comment on this
> issue:
> "... But if you need the old "strong name", you can simply use the "oldkey"
> binaries. I can't see how this is a horror, but of course I'm biased."
> doesn't seem to address the problem of conflicts.
> Also there are no guidelines for component suppliers as to which version to
> use, which increases the risk of conflicts. In the absence of explicit
> guidelines, I guess legacy components will have the old key, whereas new ones
> will tend to use the new key, since that is the only version available via
> NuGet.
> The only solution I can see is the following:
> - The "new key" assembly needs to have a different name from the "old key"
> assembly (e.g. log4net-2.dll).
> - Use Type forwarding to enable both versions to co-exist. E.g. you could
> supply a special log4net.dll signed with the old key that uses type
> forwarding to forward to log4net-2.dll signed with the new key. Or
> vice-versa.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
