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

Dominik Psenner commented on LOG4NET-397:
-----------------------------------------

You are absolutely right with your impression but I have not meant any offense. 
I don't think we are responsible for professional training of third party 
software developers, are we? :-)

However, if you're not happy what's written down in the 
[FAQ|http://logging.apache.org/log4net/release/faq.html#two-snks], open a issue 
in JIRA and write down what you want to read there.

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

Reply via email to