logging-log4net-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joe (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LOG4NET-397) Conflicts due to new strong name key
Date Tue, 08 Oct 2013 11:02:41 GMT

    [ https://issues.apache.org/jira/browse/LOG4NET-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13789105#comment-13789105

Joe commented on LOG4NET-397:

> So far I had assumed you had no influence on the suppliers

Actually I'm an independent consultant, and in some circumstances I am Supplier B, in others
I'm an application developer consuming components from external suppliers.

> There is a hypotetcical log4net 2.x which was allowed to break backwards compatibility
and so on...

I understand you need to support the current setup, and agree that the solution I proposed
is something that should be addressed in a future version.  Glad to you see you're considering
it and I'll chime in on the dev/user list if I think I have anything to add.

> 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
> 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.
> - 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

View raw message