Johannes Gustafsson | 8 Aug 22:20 2011
Picon

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
Jim Scott | 8 Aug 23:27 2011

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

Sent: Monday, August 08, 2011 1:20 PM
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.
 
Curt Arnold | 9 Aug 05:34 2011
Picon

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

Stefan Bodewig | 9 Aug 06:27 2011
Picon

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

Lee Chun Kit | 9 Aug 07:27 2011
Picon

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

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.
#avg_ls_inline_popup { position:absolute; z-index:9999; padding: 0px 0px; margin-left: 0px; margin-top: 0px; width: 240px; overflow: hidden; word-wrap: break-word; color: black; font-size: 10px; text-align: left; line-height: 13px;}
harry.douglass | 9 Aug 16:25 2011
Picon

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.

Stefan Bodewig | 10 Aug 17:38 2011
Picon

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

On 2011-08-08, Johannes Gustafsson wrote:

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

For your current situation I don't have one, sorry.  Helping to get
log4net 1.2.11 released by verifying fixes might be an option ;-)

For future releases I'd suggest to take a different approach - and this
likely is a discussion point for the dev list.  Therefore the
cross-post, please let us keep the discussion there.

I happen to be one of the ASF Incubator mentors for Lucene.NET and the
question of whether they should strong name their assembly at all and if
they should keep the signing key secret came up there for their last
release - well, they didn't really question it, I did.

Several people had good arguments towards strong naming - there are
deployment situations where it is simply necessary to use the GAC, think
BizTalk.  And several people had good arguments to simply give the
signing key away to everyone, this would help you in your case.

This seems to be consensus by now by pretty much all Open Source
projects in the .NET space.  Just hand out your signing key so people
can create their own patch builds - as they can do for any other
platform as well.  There is absolutely zero security attached to that
key if used that way, but that doesn't matter since our releases are
signed using OpenPGP and we provide hashes of everything.

I'd propose to not keep the signing key of future releases secret but
simply keep the full keypair inside the source tree.

Stefan

Jim Scott | 10 Aug 19:17 2011

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

-----Original Message----- 
From: Stefan Bodewig 
Sent: Wednesday, August 10, 2011 8:38 AM 

I'd propose to not keep the signing key of future releases secret but
simply keep the full keypair inside the source tree.

Stefan

-----------------------

I second that!

Jim

Curt Arnold | 12 Aug 06:00 2011
Picon

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.

Johannes Gustafsson | 12 Aug 07:48 2011
Picon

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

This is exactly what I need. IMHO, By not having access to the private key, log4net might as well be closed source since the ability to build it yourself is more or less gone.


/Johannes

2011/8/12 Curt Arnold <carnold <at> apache.org>

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.



Gmane