logging-log4net-dev mailing list archives

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

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

Stefan Bodewig commented on LOG4NET-397:

So far I had assumed you had no influence on the suppliers :-)

When we swiitched to the new key two years ago, there was strong demand for supporting 1.x
- believe it or not.

While the current setup may be inconvenient or in your case more than just that, breaking
existing setups that use the new-key log4net assembly by renaming it again wouldn't be a change
people would welcome either.

There is a hypotetcical log4net 2.x which was allowed to break backwards compatibility and
so on.  This one should have a different file name as well - maybe it is time to cut a 2.x
release with oldkey and newkey log4net assemblies that both contain type forwarders to a newkey
log4net2 assembly only.  I'll open a discussion for this on the dev and maybe even the user
list and we'll see where it goes.  You'd be more than welcome to voice your opinion there.
 JIRA tickets aren't really a good place for discussion, much less decision making.

> 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