[jira] [Updated] (LOG4NET-300) FilterTest doesn't compile for .Net 2.0
[ https://issues.apache.org/jira/browse/LOG4NET-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-300: --- Attachment: filter_test_2.0.patch Patch that makes FilterTest.cs compile on .NET 2.0 FilterTest doesn't compile for .Net 2.0 --- Key: LOG4NET-300 URL: https://issues.apache.org/jira/browse/LOG4NET-300 Project: Log4net Issue Type: Bug Components: Other Affects Versions: 1.2.11 Environment: .NET Framework 2.0 NAnt build on Windows Reporter: Stefan Bodewig Fix For: 1.2.11 Attachments: filter_test_2.0.patch Class MultiplePropertyFilter.Condition uses automatic properties which don't compile in a purce 2.0 environment like the one used when running the NAnt build. Fix is trivial and will be attached in a few seconds. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-302) RAT flags 90 files with missing licenses
[ https://issues.apache.org/jira/browse/LOG4NET-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-302: --- Attachment: headers.patch Adds proper license headers to all files but two readmes RAT flags 90 files with missing licenses -- Key: LOG4NET-302 URL: https://issues.apache.org/jira/browse/LOG4NET-302 Project: Log4net Issue Type: Task Components: Appenders, Builds, Core, Documentation, Examples, Other Affects Versions: 1.2.11 Reporter: Stefan Bodewig Priority: Blocker Fix For: 1.2.11 Attachments: headers.patch Can't release without fixing them but fixing will be trivial. I'll extend RAT's trunk to correctly identify .config as XML and so on so that I can use RAT itself to prepend the licenses, this will take some time. Once done I'll provide a patch fixing all files in one go. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
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
Re: Compiling log4net with strong name and 3rd party dependencies
On Aug 10, 2011, at 10:38 AM, Stefan Bodewig wrote: 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'm fine with that as long as it is a different key than that which signed the earlier releases which had some at least implied promise of signing key secrecy that we should not undo. Likely that would mean that we would need to build assemblies with the previous key for those who want a dropin replacement for earlier log4net and figure out if we want to distribute compiled assembles with the open key or just distribute the source.
Re: Compiling log4net with strong name and 3rd party dependencies
On 2011-08-11, Curt Arnold wrote: On Aug 10, 2011, at 10:38 AM, Stefan Bodewig wrote: 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'm fine with that as long as it is a different key than that which signed the earlier releases which had some at least implied promise of signing key secrecy that we should not undo. +1 That's why I proposed it for future releases. Likely that would mean that we would need to build assemblies with the previous key for those who want a dropin replacement for earlier log4net and figure out if we want to distribute compiled assembles with the open key or just distribute the source. 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. As for distributions, I think the community needs to rethink what type of assemblies should be distributed anyway - I'm not convinced separate Mono assemblies are needed anymore, for example. There may be value in assemblies that are not strong named at all in addition to those signed with an open key. Stefan
