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

Joe edited comment on LOG4NET-397 at 10/8/13 11:02 AM:
-------------------------------------------------------

> 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, trying to decide which version to use, and how to communicate about possible 
conflicts to my users.  In other circumstances 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.




was (Author: jjoe):
> 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 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