Re: Is it time to move to 2.0?

[d_k]

If log4net2.x will imply a port of log4j2 then I think we should do log4net
1.3 and remove the .NET 1.x support.


On Tue, Oct 8, 2013 at 4:13 PM, Dominik Psenner  wrote:

> >> 1.2.11 already contained breaking changes and so did 1.2.12. Thus I
> would
> >> not mind breaking backwards compatibility within 1.X even further. The
> next
> >> good milestone could be 1.3 RC1 since we won't be compatible with log4j2
> >and
> >> we should go to 2.X only if we port log4j2 features into log4net.
> >
> >At least in JIRA I've set the expectation 2.x would be the version that
> >drops .NET 1.x support.  But that can be rectified easily.
> >
> >Would you also drop .NET 1.x support in 1.3.x then?
>
> +1
>
>

[jira] [Closed] (LOG4NET-392) Updating causing Config issue

[Mark Strandness (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4NET-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Strandness closed LOG4NET-392.
---


This is a FINE company to get your software from and point their finger to 
someone else... this is NOT an INVALID issue... as others on my staff have the 
same issue. This is a BLOW OFF by Apache. I've heard from others in the company 
and all I hear is that this is a free product, but ignore the real issue. Who 
cares.. me.. I send thousands of this out to my customers. I am removing the 
free crap and will either write it myself or find a reliable software other 
than these people. Yes, I have informed Microsoft so that they remove Apache 
from their NuGet list. Hope no one else has been DUPPED by Apache?

> Updating causing Config issue
> -
>
> Key: LOG4NET-392
> URL: https://issues.apache.org/jira/browse/LOG4NET-392
> Project: Log4net
>  Issue Type: Bug
>Affects Versions: 1.2.12
> Environment: Windows 7 (64 bit) using Visual Studio 2012, NHibernate, 
> and Postgres
>Reporter: Mark Strandness
>  Labels: nuget, patch
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> I did an update yesterday from the VS 2012 NuGet Manager and afterwards, keep 
> getting a Configuration.Cfg error on my NHibernate. Found where you have 
> changed the log4net config and it added a second config for the log4net 
> package. 
> 
>   
>  \/ type="log4net.Config.Log4NetConfigurationSectionHandler,Log4net" />
>type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
>  
>   /\
> I commented out the bottom line and I now have an operational system again. 
> Small error but for the size of this system, very time consumming. Almost 
> ripped out all the log4net system to go elsewhere, but I saved it..
> Make your update soon before many other people have this same issue.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (LOG4NET-392) Updating causing Config issue

[Mark Strandness (JIRA)]

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

Mark Strandness commented on LOG4NET-392:
-

Fine... you doing it for FREE.. I acknowledge that... but if a bug is 
introduced by your program... it need to be addressed... not brushed off as 
INVALID...
Microsoft is REAL INTERESTED IN YOUR RESPONSES. I hope in the future you don't 
have to do it for FREE because you will not be included in the available 
packages . I have removed your logging system and will write my own since your 
stupid reply this morning... Thanks for making my day longer... This is going 
out to thousands of my customers and I will not accept stupidity from someone 
that wants people to use their software and not stand behind and resolve an 
issue, NO MATTER WHO is at fault. If NuGet can't fix the issue, I bet you blame 
the janitor who cleans your shitters next, huh



> Updating causing Config issue
> -
>
> Key: LOG4NET-392
> URL: https://issues.apache.org/jira/browse/LOG4NET-392
> Project: Log4net
>  Issue Type: Bug
>Affects Versions: 1.2.12
> Environment: Windows 7 (64 bit) using Visual Studio 2012, NHibernate, 
> and Postgres
>Reporter: Mark Strandness
>  Labels: nuget, patch
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> I did an update yesterday from the VS 2012 NuGet Manager and afterwards, keep 
> getting a Configuration.Cfg error on my NHibernate. Found where you have 
> changed the log4net config and it added a second config for the log4net 
> package. 
> 
>   
>  \/ type="log4net.Config.Log4NetConfigurationSectionHandler,Log4net" />
>type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
>  
>   /\
> I commented out the bottom line and I now have an operational system again. 
> Small error but for the size of this system, very time consumming. Almost 
> ripped out all the log4net system to go elsewhere, but I saved it..
> Make your update soon before many other people have this same issue.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Reopened] (LOG4NET-395) Nuget packaging problem - Creates app.config file in ALL projects when applying package.

[Stefan Bodewig (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4NET-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Bodewig reopened LOG4NET-395:



> Nuget packaging problem - Creates app.config file in ALL projects when 
> applying package.
> 
>
> Key: LOG4NET-395
> URL: https://issues.apache.org/jira/browse/LOG4NET-395
> Project: Log4net
>  Issue Type: Bug
>  Components: Builds
>Affects Versions: 1.2.9, 1.2.10, 1.2.12
>Reporter: Adam Lith
>
> When installing (or updating!) the log4net nuget package it either:
> * Adds an app.config file if none exists
> * Transforms the app.config file if one exists.
> And it does this to all the projects that you apply the package to (as always 
> with nuget).
> This is incredibly annoying because then I have to manually delete the config 
> files or revert the transformations.
> The common practice for nuget-packaging is to not perform zero transforms or 
> content-type additions and instead supply a link in the description of the 
> package to a tutorial for those that don's know how to get started.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (LOG4NET-392) Updating causing Config issue

[Mark Strandness (JIRA)]

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

Mark Strandness commented on LOG4NET-392:
-

And now who in the hell are you? OK... let's get every stupid person in here...



> Updating causing Config issue
> -
>
> Key: LOG4NET-392
> URL: https://issues.apache.org/jira/browse/LOG4NET-392
> Project: Log4net
>  Issue Type: Bug
>Affects Versions: 1.2.12
> Environment: Windows 7 (64 bit) using Visual Studio 2012, NHibernate, 
> and Postgres
>Reporter: Mark Strandness
>  Labels: nuget, patch
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> I did an update yesterday from the VS 2012 NuGet Manager and afterwards, keep 
> getting a Configuration.Cfg error on my NHibernate. Found where you have 
> changed the log4net config and it added a second config for the log4net 
> package. 
> 
>   
>  \/ type="log4net.Config.Log4NetConfigurationSectionHandler,Log4net" />
>type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
>  
>   /\
> I commented out the bottom line and I now have an operational system again. 
> Small error but for the size of this system, very time consumming. Almost 
> ripped out all the log4net system to go elsewhere, but I saved it..
> Make your update soon before many other people have this same issue.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (LOG4NET-358) Visual Studio snippet within the deployment with NuGet

[Stefan Bodewig (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4NET-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Bodewig resolved LOG4NET-358.


Resolution: Won't Fix

"invalid" is not a proper resolution for an existing bug we just can't fix.

> Visual Studio snippet within the deployment with NuGet
> --
>
> Key: LOG4NET-358
> URL: https://issues.apache.org/jira/browse/LOG4NET-358
> Project: Log4net
>  Issue Type: Wish
>  Components: Builds
> Environment: Visual Studio deployment with NuGet
>Reporter: Luciano
>Priority: Minor
>  Labels: deployment, log4net, nuget
>
> The deployment with NuGet for Visual Studio could installs also a snippet 
> which could be used to declare a private static reference to logger 
> "log4net.ILog". So, after installed the log4net via NuGet, we could just go 
> to any class and type log and a full and auto declaration appears 
> referencing the enclosure type.
> Following is a snippet I use today with C#, but needs to be installed apart 
> on each Visual Studio installation. The main piece of the snippet is the 
> declaration: private static readonly log4net.ILog log = 
> log4net.LogManager.GetLogger(typeof($classname$));
> SNIPPET DECLARATION:
> 
>  xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet";>
>   
> 
>   
> Expansion
>   
>   log4net - Declaration
>   Luciano
>   
>   
>   
>   
>   log
>   
> 
> 
>   
>   
> log4net.dll
>   
>   
>   
> 
>   classname
>   
>   
>   
>   ClassName()
>   
> 
>   
>   
>   
>   
> 
>   
> 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Reopened] (LOG4NET-358) Visual Studio snippet within the deployment with NuGet

[Stefan Bodewig (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4NET-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Bodewig reopened LOG4NET-358:



> Visual Studio snippet within the deployment with NuGet
> --
>
> Key: LOG4NET-358
> URL: https://issues.apache.org/jira/browse/LOG4NET-358
> Project: Log4net
>  Issue Type: Wish
>  Components: Builds
> Environment: Visual Studio deployment with NuGet
>Reporter: Luciano
>Priority: Minor
>  Labels: deployment, log4net, nuget
>
> The deployment with NuGet for Visual Studio could installs also a snippet 
> which could be used to declare a private static reference to logger 
> "log4net.ILog". So, after installed the log4net via NuGet, we could just go 
> to any class and type log and a full and auto declaration appears 
> referencing the enclosure type.
> Following is a snippet I use today with C#, but needs to be installed apart 
> on each Visual Studio installation. The main piece of the snippet is the 
> declaration: private static readonly log4net.ILog log = 
> log4net.LogManager.GetLogger(typeof($classname$));
> SNIPPET DECLARATION:
> 
>  xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet";>
>   
> 
>   
> Expansion
>   
>   log4net - Declaration
>   Luciano
>   
>   
>   
>   
>   log
>   
> 
> 
>   
>   
> log4net.dll
>   
>   
>   
> 
>   classname
>   
>   
>   
>   ClassName()
>   
> 
>   
>   
>   
>   
> 
>   
> 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (LOG4NET-395) Nuget packaging problem - Creates app.config file in ALL projects when applying package.

[Stefan Bodewig (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4NET-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Bodewig resolved LOG4NET-395.


Resolution: Won't Fix

"invalid" is not a proper resolution for an existing bug we just can't fix.

> Nuget packaging problem - Creates app.config file in ALL projects when 
> applying package.
> 
>
> Key: LOG4NET-395
> URL: https://issues.apache.org/jira/browse/LOG4NET-395
> Project: Log4net
>  Issue Type: Bug
>  Components: Builds
>Affects Versions: 1.2.9, 1.2.10, 1.2.12
>Reporter: Adam Lith
>
> When installing (or updating!) the log4net nuget package it either:
> * Adds an app.config file if none exists
> * Transforms the app.config file if one exists.
> And it does this to all the projects that you apply the package to (as always 
> with nuget).
> This is incredibly annoying because then I have to manually delete the config 
> files or revert the transformations.
> The common practice for nuget-packaging is to not perform zero transforms or 
> content-type additions and instead supply a link in the description of the 
> package to a tutorial for those that don's know how to get started.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (LOG4NET-392) Updating causing Config issue

[Stefan Bodewig (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4NET-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Bodewig resolved LOG4NET-392.


Resolution: Won't Fix

we'd like to see this fixed but can't fix it as the Nuget package is controlled 
by somebody else.

> Updating causing Config issue
> -
>
> Key: LOG4NET-392
> URL: https://issues.apache.org/jira/browse/LOG4NET-392
> Project: Log4net
>  Issue Type: Bug
>Affects Versions: 1.2.12
> Environment: Windows 7 (64 bit) using Visual Studio 2012, NHibernate, 
> and Postgres
>Reporter: Mark Strandness
>  Labels: nuget, patch
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> I did an update yesterday from the VS 2012 NuGet Manager and afterwards, keep 
> getting a Configuration.Cfg error on my NHibernate. Found where you have 
> changed the log4net config and it added a second config for the log4net 
> package. 
> 
>   
>  \/ type="log4net.Config.Log4NetConfigurationSectionHandler,Log4net" />
>type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
>  
>   /\
> I commented out the bottom line and I now have an operational system again. 
> Small error but for the size of this system, very time consumming. Almost 
> ripped out all the log4net system to go elsewhere, but I saved it..
> Make your update soon before many other people have this same issue.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Reopened] (LOG4NET-392) Updating causing Config issue

[Stefan Bodewig (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4NET-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Bodewig reopened LOG4NET-392:



sorry, I can't seem to change the resolution without re-opening the issue.

Mark, you are right, invalid doesn't fit as good as I thought it would.

Nobody is trying to hide anything, we are just admitting that we cannot do 
anything at all.

I've personally contacted the folks who provide the Nuget package, we are 
trying hard to cooperate.

> Updating causing Config issue
> -
>
> Key: LOG4NET-392
> URL: https://issues.apache.org/jira/browse/LOG4NET-392
> Project: Log4net
>  Issue Type: Bug
>Affects Versions: 1.2.12
> Environment: Windows 7 (64 bit) using Visual Studio 2012, NHibernate, 
> and Postgres
>Reporter: Mark Strandness
>  Labels: nuget, patch
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> I did an update yesterday from the VS 2012 NuGet Manager and afterwards, keep 
> getting a Configuration.Cfg error on my NHibernate. Found where you have 
> changed the log4net config and it added a second config for the log4net 
> package. 
> 
>   
>  \/ type="log4net.Config.Log4NetConfigurationSectionHandler,Log4net" />
>type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
>  
>   /\
> I commented out the bottom line and I now have an operational system again. 
> Small error but for the size of this system, very time consumming. Almost 
> ripped out all the log4net system to go elsewhere, but I saved it..
> Make your update soon before many other people have this same issue.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (LOG4NET-392) Updating causing Config issue

[Stefan Bodewig (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4NET-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Bodewig updated LOG4NET-392:
---

Component/s: (was: Builds)

> Updating causing Config issue
> -
>
> Key: LOG4NET-392
> URL: https://issues.apache.org/jira/browse/LOG4NET-392
> Project: Log4net
>  Issue Type: Bug
>Affects Versions: 1.2.12
> Environment: Windows 7 (64 bit) using Visual Studio 2012, NHibernate, 
> and Postgres
>Reporter: Mark Strandness
>  Labels: nuget, patch
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> I did an update yesterday from the VS 2012 NuGet Manager and afterwards, keep 
> getting a Configuration.Cfg error on my NHibernate. Found where you have 
> changed the log4net config and it added a second config for the log4net 
> package. 
> 
>   
>  \/ type="log4net.Config.Log4NetConfigurationSectionHandler,Log4net" />
>type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
>  
>   /\
> I commented out the bottom line and I now have an operational system again. 
> Small error but for the size of this system, very time consumming. Almost 
> ripped out all the log4net system to go elsewhere, but I saved it..
> Make your update soon before many other people have this same issue.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Comment Edited] (LOG4NET-392) Updating causing Config issue

[Dominik Psenner (JIRA)]

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

Dominik Psenner edited comment on LOG4NET-392 at 10/8/13 3:04 PM:
--

Hey Mark

I can feel your frustration, but you have to acknowledge we are doing this for 
free during our spare time and we can't take over other peoples projects just 
cause someone feels we would have to. To make you happy, we have contacted the 
package owner and he has resolved the issue. To the log4net project it is 
invalid, to you it has been resolved by the NuGet package maintainer.

Cheers


was (Author: nachbarslumpi):
Hey Mark

I can feel your frustration, but you have to acknowledge we are doing this for 
free during our spare time and we can't take over other peoples projects just 
cause someone feels we would have to.

Cheers

> Updating causing Config issue
> -
>
> Key: LOG4NET-392
> URL: https://issues.apache.org/jira/browse/LOG4NET-392
> Project: Log4net
>  Issue Type: Bug
>Affects Versions: 1.2.12
> Environment: Windows 7 (64 bit) using Visual Studio 2012, NHibernate, 
> and Postgres
>Reporter: Mark Strandness
>  Labels: nuget, patch
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> I did an update yesterday from the VS 2012 NuGet Manager and afterwards, keep 
> getting a Configuration.Cfg error on my NHibernate. Found where you have 
> changed the log4net config and it added a second config for the log4net 
> package. 
> 
>   
>  \/ type="log4net.Config.Log4NetConfigurationSectionHandler,Log4net" />
>type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
>  
>   /\
> I commented out the bottom line and I now have an operational system again. 
> Small error but for the size of this system, very time consumming. Almost 
> ripped out all the log4net system to go elsewhere, but I saved it..
> Make your update soon before many other people have this same issue.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (LOG4NET-392) Updating causing Config issue

[Dominik Psenner (JIRA)]

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

Dominik Psenner commented on LOG4NET-392:
-

Hey Mark

I can feel your frustration, but you have to acknowledge we are doing this for 
free during our spare time and we can't take over other peoples projects just 
cause someone feels we would have to.

Cheers

> Updating causing Config issue
> -
>
> Key: LOG4NET-392
> URL: https://issues.apache.org/jira/browse/LOG4NET-392
> Project: Log4net
>  Issue Type: Bug
>  Components: Builds
>Affects Versions: 1.2.12
> Environment: Windows 7 (64 bit) using Visual Studio 2012, NHibernate, 
> and Postgres
>Reporter: Mark Strandness
>  Labels: nuget, patch
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> I did an update yesterday from the VS 2012 NuGet Manager and afterwards, keep 
> getting a Configuration.Cfg error on my NHibernate. Found where you have 
> changed the log4net config and it added a second config for the log4net 
> package. 
> 
>   
>  \/ type="log4net.Config.Log4NetConfigurationSectionHandler,Log4net" />
>type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
>  
>   /\
> I commented out the bottom line and I now have an operational system again. 
> Small error but for the size of this system, very time consumming. Almost 
> ripped out all the log4net system to go elsewhere, but I saved it..
> Make your update soon before many other people have this same issue.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (LOG4NET-392) Updating causing Config issue

[Mark Strandness (JIRA)]

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

Mark Strandness commented on LOG4NET-392:
-

That's fine... PLEASE REMOVE the "INVALID" as this issue has been" VALIDATED" . 
Just replace the INVALID to "can't fix because we don't give a damn"...
I guess you'll get more of this issue from others because you don't care, but 
make it so that others do see the issue and know that it is an issue and there 
is a solution to it and not have to spend hours tracking it down. That would be 
nice. I looked on your site and there was nothing reported. Made the report and 
now you want to sweep under the rug. Are you too lazy to contact NuGet to find 
the issue and repair this bug? Can't you people work together?

Thanks for building my faith in a MAJOR issue becoming someone else's issue. I 
bet you've been doing that for so many years, it just makes you feel 
comfortable. Typical developer... it's not my issue, it is the next person down 
the line... Make me feel good about using your software. I will be looking 
elsewhere for other software so not to have an issue with you in the future... 
WHEW... glad I found out NOW how worthless you are!

On to extraview.com to report your issue that you claim is INVALID and make a 
bigger stink out there on you... maybe drive your product into the ground. Also 
on to Microsoft and let them know how un-compatible you are  to their software 
and blame you for the issue in your software. Maybe they even knock you off 
your pedestal and find a better logger. Wait til they hear about you 
introducing errors and CREATING an invalid bug into their software. Wonder if 
Microsoft reported this to you already and you IGNORED them also

Good Luck in the future... what you have left of it... KMA


> Updating causing Config issue
> -
>
> Key: LOG4NET-392
> URL: https://issues.apache.org/jira/browse/LOG4NET-392
> Project: Log4net
>  Issue Type: Bug
>  Components: Builds
>Affects Versions: 1.2.12
> Environment: Windows 7 (64 bit) using Visual Studio 2012, NHibernate, 
> and Postgres
>Reporter: Mark Strandness
>  Labels: nuget, patch
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> I did an update yesterday from the VS 2012 NuGet Manager and afterwards, keep 
> getting a Configuration.Cfg error on my NHibernate. Found where you have 
> changed the log4net config and it added a second config for the log4net 
> package. 
> 
>   
>  \/ type="log4net.Config.Log4NetConfigurationSectionHandler,Log4net" />
>type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
>  
>   /\
> I commented out the bottom line and I now have an operational system again. 
> Small error but for the size of this system, very time consumming. Almost 
> ripped out all the log4net system to go elsewhere, but I saved it..
> Make your update soon before many other people have this same issue.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Closed] (LOG4NET-395) Nuget packaging problem - Creates app.config file in ALL projects when applying package.

[Dominik Psenner (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4NET-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dominik Psenner closed LOG4NET-395.
---

Resolution: Invalid

This is "invalid" as we don't control the nuget package.

See also 
http://blog.cincura.net/233419-log4net-nuget-package-updated-without-some-goodies/
 and https://github.com/cincuranet/log4net-nuget

If the issue persists, I'd encourage you to open an issue at github

> Nuget packaging problem - Creates app.config file in ALL projects when 
> applying package.
> 
>
> Key: LOG4NET-395
> URL: https://issues.apache.org/jira/browse/LOG4NET-395
> Project: Log4net
>  Issue Type: Bug
>  Components: Builds
>Affects Versions: 1.2.9, 1.2.10, 1.2.12
>Reporter: Adam Lith
>
> When installing (or updating!) the log4net nuget package it either:
> * Adds an app.config file if none exists
> * Transforms the app.config file if one exists.
> And it does this to all the projects that you apply the package to (as always 
> with nuget).
> This is incredibly annoying because then I have to manually delete the config 
> files or revert the transformations.
> The common practice for nuget-packaging is to not perform zero transforms or 
> content-type additions and instead supply a link in the description of the 
> package to a tutorial for those that don's know how to get started.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

AW: NuGet package distribution

[Dominik Psenner]

>> Given the noise, an entry in the FAQ could be wise.
>
>Probably - and maybe a pointer from the download page.
>
>I'll take care of it tomorrow unless you beat me to it.

Please, take your time. :-)

[jira] [Updated] (LOG4NET-392) Updating causing Config issue

[Stefan Bodewig (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4NET-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Bodewig updated LOG4NET-392:
---

Labels: nuget patch  (was: patch)

> Updating causing Config issue
> -
>
> Key: LOG4NET-392
> URL: https://issues.apache.org/jira/browse/LOG4NET-392
> Project: Log4net
>  Issue Type: Bug
>  Components: Builds
>Affects Versions: 1.2.12
> Environment: Windows 7 (64 bit) using Visual Studio 2012, NHibernate, 
> and Postgres
>Reporter: Mark Strandness
>  Labels: nuget, patch
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> I did an update yesterday from the VS 2012 NuGet Manager and afterwards, keep 
> getting a Configuration.Cfg error on my NHibernate. Found where you have 
> changed the log4net config and it added a second config for the log4net 
> package. 
> 
>   
>  \/ type="log4net.Config.Log4NetConfigurationSectionHandler,Log4net" />
>type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
>  
>   /\
> I commented out the bottom line and I now have an operational system again. 
> Small error but for the size of this system, very time consumming. Almost 
> ripped out all the log4net system to go elsewhere, but I saved it..
> Make your update soon before many other people have this same issue.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (LOG4NET-392) Updating causing Config issue

[Stefan Bodewig (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4NET-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Bodewig resolved LOG4NET-392.


Resolution: Invalid

This is "invalid" as we don't control the nuget package.

See also 
http://blog.cincura.net/233419-log4net-nuget-package-updated-without-some-goodies/
 and https://github.com/cincuranet/log4net-nuget

If the issue persists, I'd encourage you to open an issue at github

> Updating causing Config issue
> -
>
> Key: LOG4NET-392
> URL: https://issues.apache.org/jira/browse/LOG4NET-392
> Project: Log4net
>  Issue Type: Bug
>  Components: Builds
>Affects Versions: 1.2.12
> Environment: Windows 7 (64 bit) using Visual Studio 2012, NHibernate, 
> and Postgres
>Reporter: Mark Strandness
>  Labels: nuget, patch
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> I did an update yesterday from the VS 2012 NuGet Manager and afterwards, keep 
> getting a Configuration.Cfg error on my NHibernate. Found where you have 
> changed the log4net config and it added a second config for the log4net 
> package. 
> 
>   
>  \/ type="log4net.Config.Log4NetConfigurationSectionHandler,Log4net" />
>type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
>  
>   /\
> I commented out the bottom line and I now have an operational system again. 
> Small error but for the size of this system, very time consumming. Almost 
> ripped out all the log4net system to go elsewhere, but I saved it..
> Make your update soon before many other people have this same issue.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (LOG4NET-358) Visual Studio snippet within the deployment with NuGet

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig commented on LOG4NET-358:


see also 
http://blog.cincura.net/233419-log4net-nuget-package-updated-without-some-goodies/
 and https://github.com/cincuranet/log4net-nuget

If the issue persists, I'd encourage you to open an issue at github

> Visual Studio snippet within the deployment with NuGet
> --
>
> Key: LOG4NET-358
> URL: https://issues.apache.org/jira/browse/LOG4NET-358
> Project: Log4net
>  Issue Type: Wish
>  Components: Builds
> Environment: Visual Studio deployment with NuGet
>Reporter: Luciano
>Priority: Minor
>  Labels: deployment, log4net, nuget
>
> The deployment with NuGet for Visual Studio could installs also a snippet 
> which could be used to declare a private static reference to logger 
> "log4net.ILog". So, after installed the log4net via NuGet, we could just go 
> to any class and type log and a full and auto declaration appears 
> referencing the enclosure type.
> Following is a snippet I use today with C#, but needs to be installed apart 
> on each Visual Studio installation. The main piece of the snippet is the 
> declaration: private static readonly log4net.ILog log = 
> log4net.LogManager.GetLogger(typeof($classname$));
> SNIPPET DECLARATION:
> 
>  xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet";>
>   
> 
>   
> Expansion
>   
>   log4net - Declaration
>   Luciano
>   
>   
>   
>   
>   log
>   
> 
> 
>   
>   
> log4net.dll
>   
>   
>   
> 
>   classname
>   
>   
>   
>   ClassName()
>   
> 
>   
>   
>   
>   
> 
>   
> 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Re: NuGet package distribution

[Stefan Bodewig]

On 2013-10-08, Dominik Psenner wrote:

>> Never heard back, but with
>> > some-goodies/>
>> and  we could simply point
>> people to github and close all Nuget related issues immediately.

> +1

> Given the noise, an entry in the FAQ could be wise.

Probably - and maybe a pointer from the download page.

I'll take care of it tomorrow unless you beat me to it.

Stefan

AW: NuGet package distribution

[Dominik Psenner]

>Never heard back, but with
>some-goodies/>
>and  we could simply point
>people to github and close all Nuget related issues immediately.

+1

Given the noise, an entry in the FAQ could be wise.

Re: NuGet package distribution

[Stefan Bodewig]

On 2013-10-04, Stefan Bodewig wrote:

> I've contacted "cincura.net" via the NuGet website and hope to hear
> back.  It would be great to have her/him on board addressing the
> packaging related issues and maybe help streamline the process of
> publishing future packages.

Never heard back, but with

and  we could simply point
people to github and close all Nuget related issues immediately.

Stefan

[jira] [Commented] (LOG4NET-395) Nuget packaging problem - Creates app.config file in ALL projects when applying package.

[Mark Ward (JIRA)]

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

Mark Ward commented on LOG4NET-395:
---

The owner of the nuget package has made a post he has fixed the package.

http://blog.cincura.net/233419-log4net-nuget-package-updated-without-some-goodies/


> Nuget packaging problem - Creates app.config file in ALL projects when 
> applying package.
> 
>
> Key: LOG4NET-395
> URL: https://issues.apache.org/jira/browse/LOG4NET-395
> Project: Log4net
>  Issue Type: Bug
>  Components: Builds
>Affects Versions: 1.2.9, 1.2.10, 1.2.12
>Reporter: Adam Lith
>
> When installing (or updating!) the log4net nuget package it either:
> * Adds an app.config file if none exists
> * Transforms the app.config file if one exists.
> And it does this to all the projects that you apply the package to (as always 
> with nuget).
> This is incredibly annoying because then I have to manually delete the config 
> files or revert the transformations.
> The common practice for nuget-packaging is to not perform zero transforms or 
> content-type additions and instead supply a link in the description of the 
> package to a tutorial for those that don's know how to get started.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

AW: Is it time to move to 2.0?

[Dominik Psenner]

>> 1.2.11 already contained breaking changes and so did 1.2.12. Thus I would
>> not mind breaking backwards compatibility within 1.X even further. The
next
>> good milestone could be 1.3 RC1 since we won't be compatible with log4j2
>and
>> we should go to 2.X only if we port log4j2 features into log4net.
>
>At least in JIRA I've set the expectation 2.x would be the version that
>drops .NET 1.x support.  But that can be rectified easily.
>
>Would you also drop .NET 1.x support in 1.3.x then?

+1

Re: Is it time to move to 2.0?

[Stefan Bodewig]

On 2013-10-08, Dominik Psenner wrote:

> 1.2.11 already contained breaking changes and so did 1.2.12. Thus I would
> not mind breaking backwards compatibility within 1.X even further. The next
> good milestone could be 1.3 RC1 since we won't be compatible with log4j2 and
> we should go to 2.X only if we port log4j2 features into log4net.

At least in JIRA I've set the expectation 2.x would be the version that
drops .NET 1.x support.  But that can be rectified easily.

Would you also drop .NET 1.x support in 1.3.x then?

Stefan

AW: Is it time to move to 2.0?

[Dominik Psenner]

1.2.11 already contained breaking changes and so did 1.2.12. Thus I would
not mind breaking backwards compatibility within 1.X even further. The next
good milestone could be 1.3 RC1 since we won't be compatible with log4j2 and
we should go to 2.X only if we port log4j2 features into log4net.

[jira] [Comment Edited] (LOG4NET-397) Conflicts due to new strong name key

[Joe (JIRA)]

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

[jira] [Commented] (LOG4NET-397) Conflicts due to new strong name key

[Joe (JIRA)]

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

Is it time to move to 2.0?

[Stefan Bodewig]

Hi all,

not sure whether I find an audience big enough or whether we need to
expand this to the user list.

One option to get out of the oldkey/newkey problems mentioned in
https://issues.apache.org/jira/browse/LOG4NET-397 would be to make the
move to a log4net2 assembly.

The short term plan would be:

* branch off a 1.x branch from trunk in case we want to do a 1.2.13
  release one day

* remove the 1.x, Mono 1.x and compact framework builds

* start ripping out the .NET 1.x compatibility code as well as all
  NET_20 conditionals

* rename assembly to log4net2 - only sign it with the "new key"

* create log4net assemblies holding type forwarders to log4net2 -
  provide two versions with either key

* release soon

Pros:

* allows us to build all of log4net on Windows7 - right now I must keep
  an XP VM around and we all know XP will see an end of live soon.

* fixes the binding problems

Cons:

* lognet4 2.x would look like log4j 1.x not 2.x - this might confuse
  people.  Then again I don't envision us to port log4j2 any time soon
  because of our sheer lack of manpower.

* we'd lose an opportunity to remove more stuff we'd like to break
  backwards compatibility on - at least if "release soon" was taken
  seriously

WDYT?

Stefan

[jira] [Commented] (LOG4NET-397) Conflicts due to new strong name key

[Stefan Bodewig (JIRA)]

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

[jira] [Commented] (LOG4NET-397) Conflicts due to new strong name key

[Joe (JIRA)]

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

Joe commented on LOG4NET-397:
-

>  Using a privatePath attribute on a probing element in your application's 
> config you should be able to load both versions.

I can load both versions with appropriate configuration (e.g. using a 
runtime/assemblyBinding/dependentAssembly/codeBase element).  But this isn't a 
complete solution, as the two loaded versions can still conflict (e.g. use the 
same FileAppender).  And there are other problems: e.g. I have an 
administrative UI that displays all configured loggers and allows the logging 
level to be configured dynamically.  This would only see the configured loggers 
for its own version of log4net.

> Right now renaming won't help in your case, would it? AssemblyB would still 
> be bound to the name log4net.
That's true, but if you agreed that the combination "new key + same filename" 
was a mistake, and implemented my suggestion, I'd have a strong case for asking 
Supplier B to migrate to this new solution.

> type forwarding wouldn't work for 1.x
Even in the slow-moving enterprise environment where I work, nobody develops 
any more with 1.x.  

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

[jira] [Commented] (LOG4NET-397) Conflicts due to new strong name key

[Joe (JIRA)]

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

Joe commented on LOG4NET-397:
-

> "... if a third party library uses log4net and another third party library 
> uses another version of log4net, then the dependencies have to be fixed in 
> either or both of the third party libraries".

If I have the ability to fix the conflicting libraries, I can use a single 
version of log4net and the problem doesn't arise.  But the reality is that 
third party libraries can't always be fixed, or at least not in a timely 
manner. 

> Deployment issues have to be addresses...

This is more than a deployment issue.  

> I can see no way how we could fix problems others create by referencing/using 
> log4net badly.

I don't see who is referencing log4net "badly".  Supplier A used the old strong 
name key, which was the only one available when he shipped his component.  
Supplier B used the new strong name, which seems to be what is recommended 
currently, and is what he'll get if he uses NuGet to obtain log4net.

The "fix" in my view is what I suggested: the "new key" version should have a 
different filename, and you should consider shipping a special "old key" 
version of log4net that uses Type forwarding to forward to the new version.  In 
this way components from both Supplier A and Supplier B can be included in an 
application without conflict.


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

[jira] [Commented] (LOG4NET-397) Conflicts due to new strong name key

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig commented on LOG4NET-397:


type forwarding wouldn't work for 1.x - I could claim this is the reason we 
didn't use them even if this isn't true.  But in fact if we had thought of type 
forwards this would have ruled out the solution.

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

[jira] [Commented] (LOG4NET-397) Conflicts due to new strong name key

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig commented on LOG4NET-397:


Joe, you are right.  When we considered switching to a new strong name key, the 
scenario of two different dependencies requiring two different strong names 
never came up.  Back then type forwarding might have been the better option, 
but unfortunately nobobdy thought of it.

Right now renaming won't help in your case, would it?  AssemblyB would still be 
bound to the name log4net.

>From the top of my head and without having a .NET installation at hand to try 
>my theory: you could create subdirectories inside your application directory 
>and place the two log4net assemblies in separate subdirs. Using a privatePath 
>attribute on a probing element in your application's config you should be able 
>to load both versions.

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

[jira] [Comment Edited] (LOG4NET-397) Conflicts due to new strong name key

[Dominik Psenner (JIRA)]

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

Dominik Psenner edited comment on LOG4NET-397 at 10/8/13 8:57 AM:
--

1. If the GAC's no option, then maybe a version wildcard is. I.e. in your case 
tell the assembly that's using log4net to accept every log4net version matching 
1.2.*
2. That's something that has to be considered and fixed with whatever is 
appropriate for the application. That could be locking models, PID files that 
prevent multiple processes to be running at the same time, .. etc.

In general: log4net does not provide installers and thus delegates deployment 
to whoever uses log4net. I can see no way how we could fix problems others 
create by referencing/using log4net badly.

In your usecase: if a third party library uses log4net and another third party 
library uses another version of log4net, then the dependencies have to be fixed 
in either or both of the third party libraries.


was (Author: nachbarslumpi):
1. If the GAC's no option, then maybe a version wildcard is. I.e. in your case 
tell the assembly that's using log4net to accept every log4net version matching 
1.2.*
2. That's something that has to be considered and fixed with whatever is 
appropriate for the application. That could be locking models, PID files that 
prevent multiple processes to be running at the same time, .. etc.

In general: log4net does not provide installers and thus delegates deployment 
to whoever uses log4net. I can see no way how we could fix problems others 
create by referencing/using log4net badly.

If a third party library uses log4net and another third party library uses 
another version of log4net, then the dependencies have to be fixed in either or 
both of the third party libraries.

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

[jira] [Resolved] (LOG4NET-397) Conflicts due to new strong name key

[Dominik Psenner (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4NET-397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dominik Psenner resolved LOG4NET-397.
-

Resolution: Invalid

Deployment issues have to be addressed by whoever's using log4net.

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

[jira] [Commented] (LOG4NET-397) Conflicts due to new strong name key

[Dominik Psenner (JIRA)]

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

Dominik Psenner commented on LOG4NET-397:
-

1. If the GAC's no option, then maybe a version wildcard is. I.e. in your case 
tell the assembly that's using log4net to accept every log4net version matching 
1.2.*
2. That's something that has to be considered and fixed with whatever is 
appropriate for the application. That could be locking models, PID files that 
prevent multiple processes to be running at the same time, .. etc.

In general: log4net does not provide installers and thus delegates deployment 
to whoever uses log4net. I can see no way how we could fix problems others 
create by referencing/using log4net badly.

If a third party library uses log4net and another third party library uses 
another version of log4net, then the dependencies have to be fixed in either or 
both of the third party libraries.

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

[jira] [Commented] (LOG4NET-397) Conflicts due to new strong name key

[Joe (JIRA)]

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

Joe commented on LOG4NET-397:
-

> ... it may be time to learn about the GAC

1. I know about the GAC, but it's not always an option.  E.g. requires 
administrator privileges, and is not available in a hosting environment.

2. Even if the GAC is used, there are potential conflicts.  For example, if two 
versions of log4net are loaded, and both read the same config file (e.g. using 
the appSetting log4net.Config), you could end up with both versions attempting 
to write to the same file appender.


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

[jira] [Commented] (LOG4NET-395) Nuget packaging problem - Creates app.config file in ALL projects when applying package.

[Dominik Psenner (JIRA)]

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

Dominik Psenner commented on LOG4NET-395:
-

FWIW, you can contact the owner by following the link at the NuGet's package 
homepage.

> Nuget packaging problem - Creates app.config file in ALL projects when 
> applying package.
> 
>
> Key: LOG4NET-395
> URL: https://issues.apache.org/jira/browse/LOG4NET-395
> Project: Log4net
>  Issue Type: Bug
>  Components: Builds
>Affects Versions: 1.2.9, 1.2.10, 1.2.12
>Reporter: Adam Lith
>
> When installing (or updating!) the log4net nuget package it either:
> * Adds an app.config file if none exists
> * Transforms the app.config file if one exists.
> And it does this to all the projects that you apply the package to (as always 
> with nuget).
> This is incredibly annoying because then I have to manually delete the config 
> files or revert the transformations.
> The common practice for nuget-packaging is to not perform zero transforms or 
> content-type additions and instead supply a link in the description of the 
> package to a tutorial for those that don's know how to get started.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (LOG4NET-395) Nuget packaging problem - Creates app.config file in ALL projects when applying package.

[Peter Murphy (JIRA)]

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

Peter Murphy commented on LOG4NET-395:
--

I signed up just to report on the issue.

I have been using version 2.0.1 of NuGet's packaging of Log4Net happily - that 
is tied to version 1.2.12 of your release. It logs to console and files - as I 
wanted. 

Now the people that are maintaining the NuGet version of Log4Net have slipped 
in a new version 2.0.2. This seems to be redundant, since that's also tied to 
1.2.12. Moreover, it seems to have "broken" the code. I can log to a file with 
2.0.1, but when I upgrade to 2.0.2, the file logging code now doesn't work.

I don't know who to complain to about it. Does anyone know? 

> Nuget packaging problem - Creates app.config file in ALL projects when 
> applying package.
> 
>
> Key: LOG4NET-395
> URL: https://issues.apache.org/jira/browse/LOG4NET-395
> Project: Log4net
>  Issue Type: Bug
>  Components: Builds
>Affects Versions: 1.2.9, 1.2.10, 1.2.12
>Reporter: Adam Lith
>
> When installing (or updating!) the log4net nuget package it either:
> * Adds an app.config file if none exists
> * Transforms the app.config file if one exists.
> And it does this to all the projects that you apply the package to (as always 
> with nuget).
> This is incredibly annoying because then I have to manually delete the config 
> files or revert the transformations.
> The common practice for nuget-packaging is to not perform zero transforms or 
> content-type additions and instead supply a link in the description of the 
> package to a tutorial for those that don's know how to get started.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (LOG4NET-397) Conflicts due to new strong name key

[Dominik Psenner (JIRA)]

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

Dominik Psenner commented on LOG4NET-397:
-

Since you have to share assemblies, it may be time to learn about the GAC:

http://msdn.microsoft.com/en-us/library/yf1d93sz.aspx

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

[jira] [Commented] (LOG4NET-397) Conflicts due to new strong name key

[Dominik Psenner (JIRA)]

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

Dominik Psenner commented on LOG4NET-397:
-

Since you have to share assemblies, it may be time to learn about the GAC:

http://msdn.microsoft.com/en-us/library/yf1d93sz.aspx

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

[jira] [Updated] (LOG4NET-397) Conflicts due to new strong name key

[Joe (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4NET-397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joe updated LOG4NET-397:


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



  was:
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-342 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.




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