Compiling log4net with strong name and 3rd party dependencies

Re: Compiling log4net with strong name and 3rd party dependencies

Re: Compiling log4net with strong name and 3rd party dependencies (also is log4net in a cul-du-sac)

I wrote this message last night in response to the is log4net in a cul-du-sac thread, but it got bounced due to
a spam guard which I've hopefully satisfied this time.   The strong naming key that has been used to sign
log4net releases has been encrypted and can be decrypted using the private keys of several people
including myself. I'd be happy to perform the release build or reencrypt the strong signing key to another
PMC member who wants to help. However, to get to that point, it will take people who are motivated to pitch in
and get things ready for release. Further discussion should be on log4net-dev. 

My message from last night:

I'm not sure if this message got an adequate answer.

For those who want to drive a release forward, I would suggest:

Create a bug report for the next release (check if there is already one)

Make that bug dependent on any issue that you think needs to be resolved before the next release

If there are any debatable issues (like dropping support for earlier .NET versions), start a vote on the
mailing list. If there are interrelated issues, perhaps create a page on the logging wiki and have a vote on
all the issues in the same time.

If there are bugs without test cases or patches, create test cases and patches.

If there are bugs with test case and patches that should be committed, make a comment on the bug that it
appears ready to go.

Hopefully through this process, we can develop the track record that will allow adding some new committers
or PMC members.

On Aug 8, 2011, at 4:27 PM, Jim Scott wrote:

> From: Johannes Gustafsson
> Sent: Monday, August 08, 2011 1:20 PM
> To: log4net-user <at> logging.apache.org
> Subject: Compiling log4net with strong name and 3rd party dependencies
> Hi,
>  
> There are a few bugfixes in the trunk that I need and since there has been no new release for a very long time, I
tried to compile it myself. I created a key and have successfully compiled it with no problems. However, I
have quite a few 3rd party dependencies that themselves are dependent on log4net. These dependencies
can't find load the new assembly that I have created because they require that it is signed with a key that I
dont have access to. So this means that I can't use my own version of log4net without recompiling all my dependencies.
>  
> Do you have any suggestions to how I can solve this?
>  
> Regards,
> /Johannes
>  
>  
> Yes, this is the same issue we have. I have a few features I would like to add but the thought of having to
recompile everything has kept me from doing so.
>  

Re: Compiling log4net with strong name and 3rd party dependencies (also is log4net in a cul-du-sac)

[cross-posted so people don't duplicate effort, rest should only happen
on the dev list]

On 2011-08-09, Stefan Bodewig wrote:

> On 2011-08-09, Curt Arnold wrote:

>> For those who want to drive a release forward, I would suggest:

>> Create a bug report for the next release (check if there is already
>> one)

> I'm not sure we need a separate issue for the release itself when JIRA
> provides the roadmap view.

Created one anyway <https://issues.apache.org/jira/browse/LOG4NET-299>

Stefan

Re: Compiling log4net with strong name and 3rd party dependencies

Error email not sent when number of error events less than flush value and flush time interval

Hi, Everyone.

I was trying to use the popular SmtpCachingAppender code by Ken Parrish
found at this link:
http://www.l4ndash.com/Log4NetMailArchive/tabid/70/forumid/1/tpage/1/view/topic/postid/18721/Default.aspx#18722

However, my issue is this, when I get an error or errors less than the
flush value or time interval, then no emails are sent therefore I don't
know that something happened (unless I manually check the error log).  What
I need is let's say one error happens, like a file is not received,  I need
to know the smallest to the greatest of application errors, but his set up
only accounts for MAJOR error events that has to meet a flush criteria.

Can anyone tell me what they did for this scenario if using Ken's approach?
Ken, can you assist with an update for this situation?

Thanks in advance.

--Harry

The contents of this email are the property of PNC. If it was not addressed to you, you have no legal right to
read it. If you think you received it in error, please notify the sender. Do not forward or copy without
permission of the sender. This message may contain an advertisement of a product or service and thus may
constitute a commercial electronic mail message under US Law. The postal address for PNC is 249 Fifth
Avenue, Pittsburgh, PA 15222. If you do not wish to receive any additional advertising or promotional
messages from PNC at this e-mail address, click here to unsubscribe.
https://pnc.p.delivery.net/m/u/pnc/uni/p.asp By unsubscribing to this message, you will be
unsubscribed from all advertising or promotional messages from PNC. Removing your e-mail address from
this mailing 
 list will not affect your subscription to alerts, e-newsletters or account servicing e-mails.

Re: Compiling log4net with strong name and 3rd party dependencies

On Aug 11, 2011, at 12:16 AM, Stefan Bodewig wrote:
> 
> Right now I'd lean towards making breaking changes for a 1.3.x line of
> releases and using the new key there, I'm not sure whether signing those
> with the old key would be useful at all.

The following email describes a situation where a new log4net signed with the existing key would be very
handy. We'd need to nuance the message so that most people who don't have a need for the drop in compatible
old-key signed assemblies link against the new key signed binaries.

If we are disclosing the a common unsecret key, then the need to address every platform nuance is much
reduced and we can just direct someone who needs a build for a specific variant of .NET or Mono to build it themselves.

It may be premature, but if someone wants to up some sort of poll to determine which variants to try to support
and test, please take the initiative.

On Aug 9, 2011, at 12:27 AM, Lee Chun Kit wrote:

> On Tue, Aug 9, 2011 at 4:20 AM, Johannes Gustafsson <johannesgu <at> gmail.com> wrote:
> Hi,
> 
> There are a few bugfixes in the trunk that I need and since there has been no new release for a very long time, I
tried to compile it myself. I created a key and have successfully compiled it with no problems. However, I
have quite a few 3rd party dependencies that themselves are dependent on log4net. These dependencies
can't find load the new assembly that I have created because they require that it is signed with a key that I
dont have access to. So this means that I can't use my own version of log4net without recompiling all my dependencies.
> 
> Do you have any suggestions to how I can solve this?
> 
> Regards,
> /Johannes
> 
> If your 3rd party dependencies don't require the bug fixes, you could maintain two different references.
Just a suggestion.

Re: Compiling log4net with strong name and 3rd party dependencies

Re: Compiling log4net with strong name and 3rd party dependencies

On 2011-08-12, Curt Arnold wrote:

> On Aug 11, 2011, at 12:16 AM, Stefan Bodewig wrote:

>> Right now I'd lean towards making breaking changes for a 1.3.x line of
>> releases and using the new key there, I'm not sure whether signing those
>> with the old key would be useful at all.

> The following email describes a situation where a new log4net signed
> with the existing key would be very handy.

Yes, I know.

Getting out a new release containing those bug fixes using the existing
key should be a top priority.  Questions like "hat platforms do we want
to support" can come later.

> We'd need to nuance the message so that most people who don't have a
> need for the drop in compatible old-key signed assemblies link against
> the new key signed binaries.

Or one that doesn't have a strong name at all.

> If we are disclosing the a common unsecret key, then the need to
> address every platform nuance is much reduced and we can just direct
> someone who needs a build for a specific variant of .NET or Mono to
> build it themselves.

Right, that's why I proposed to not keep the new key secret - secret
keys and open source simply don't match.

I do understand that some existing users may have some (false, TBH)
ideas about security attached to the old key and thus you don't want to
disclose that as well - even though it would simplify the migration a
lot (there wouldn't be any sort of migration at all).

Stefan

Log4Net losing renderer information on web app restart