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 Wed, 09 Oct 2013 12:57:42 GMT

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

Joe commented on LOG4NET-397:
-----------------------------

@Dominik, no offence taken.  My opinion, as you'll have gathered above, could be summarized
by adding a FAQ entry that makes the points below.  But I don't see the point in opening a
second JIRA issue for this, particularly since it seems evident that you guys don't agree
with me.

- It was a mistake to release two versions of log4net with the same assembly name and two
different strong name keys, because of the potential for conflicts between 3rd party components
that use different versions of log4net.

- Log4net users who could be potentially affected by this conflict (component suppliers; developers
who use 3rd party components that might include log4net) are recommended to continue using
the old key, to minimize the risk of conflicts.

- The FAQ might mention whatever work is being done for a future V2 (use of a different assembly
name and possible type forwarding) to avoid such conflicts.

If this were in the FAQ, a consequence would be that the NuGet owners should produce a version
with the old key, and make the same recommendations to their users.

'Nuff said.  I'm happy to see that Sfefan at least seems to have taken on board that this
is a genuine problem, and I hope it will be addressed in a future version as he indicated
it might.

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

Mime
View raw message