RE: ADO.NET Appender and FX 4.0
I should add that NAnt.exe.config contains NetFx40_LegacySecurityPolicy enabled=true/ and seems to need it. This may complicate things even further. See this http://msdn.microsoft.com/en-us/library/dd409253.aspx My gut says that this setting is a BAD thing. 1) - It is a RUNTIME not COMPILE time setting. If code for legacy security being enabled, then anyone that uses log4Net will have to specify legacy security and that is just not going to work very well. 2) - It should only be set for code that explicitly defines a CAS policy.3) - From reading more MS documents, this setting appears to be a migration setting and we should not plan on running that way indefinitely. I think we are already in too deep to make a 4.0 target for the 1.2.11 release because we are going to have to 1) - Understand the new (non) CAS security model 2) - Make code changes to support it Now, that I have written all of this, I assume NAnt.exe.config is the config file for NAnt, not for what it builds. If so, then this setting is simply telling the NAnt runtime to run with legacy security and that is not even meaningful unless NAnt is targeted to 4.0 -- Roy Chastain
Re: ADO.NET Appender and FX 4.0
On 2011-08-20, Roy Chastain wrote: I should add that NAnt.exe.config contains NetFx40_LegacySecurityPolicy enabled=true/ and seems to need it. This may complicate things even further. See this http://msdn.microsoft.com/en-us/library/dd409253.aspx Yes, I knew that, I should have elaborated more. My gut says that this setting is a BAD thing. 1) - It is a RUNTIME not COMPILE time setting. If code for legacy security being enabled, then anyone that uses log4Net will have to specify legacy security and that is just not going to work very well. It is NAnt that seems to need it so it is inside the NAnt.exe.config. And what I meant to say was that it is complicating things for running the tests as it applies to the testcases - unless the NUnit task in NAnt forks a new process, that is. 2) - It should only be set for code that explicitly defines a CAS policy. NAnt apparently does. 3) - From reading more MS documents, this setting appears to be a migration setting and we should not plan on running that way indefinitely. I'm not suggesting we should recommend any such setting for log4net at all. I think we are already in too deep to make a 4.0 target for the 1.2.11 release because we are going to have to 1) - Understand the new (non) CAS security model 2) - Make code changes to support it +1 [for those new to the ASF, you're going to see this frequently as this is how we vote and +/-1 has crept into non-vote discussions as well. +1 simply means I agree in this case and I just typed it out of habit.] Now, that I have written all of this, I assume NAnt.exe.config is the config file for NAnt, not for what it builds. If so, then this setting is simply telling the NAnt runtime to run with legacy security and that is not even meaningful unless NAnt is targeted to 4.0 Errm, should have read up to here before I started responding. 8-) Yes. Stefan
RE: ADO.NET Appender and FX 4.0
While, this is certainly a problem, it SHOULD not be the issue already reported, because those reports were against log4Net running on the 2.0 CLR instead of the 4.0 CLR. I have done some research this morning, and have found a couple of articles suggesting fixes, but I do not yet understand the ramifications. This is all to do with a new code security model created in 4.0 and it is going to take time to understand. If anyone reading this is a 4.0 code security model guru, then please look at http://connect.microsoft.com/VisualStudio/feedback/details/464751/inheri tance-security-rules-violated-while-overriding-member and throw out an opinion. The other solution seems to involve marking the calling code, but I have not figured it all out as yet. -- Roy Chastain -Original Message- From: Stefan Bodewig [mailto:bode...@apache.org] Sent: Thursday, August 18, 2011 23:41 To: log4net-dev@logging.apache.org Subject: ADO.NET Appender and FX 4.0 Hi, Roy said in some thread people had reported problems with the ADO.NET appender when running on .NET 4.0. I managed to get to the point where NAnt at least tries to run the unit tests on 4.0 and this is what I see: Unhandled Exception: System.TypeLoadException: Inheritance security rules violated while overriding member: 'log4net.Core.LoggingEvent.GetObjectData(System.Runtime.Serialization.Se rializationInfo, System.Runtime.Serialization.StreamingContext)'. Security accessibility of the overriding method must match the security accessibility of the method being overriden. at log4net.Appender.BufferingAppenderSkeleton.Flush(Boolean flushLossyBuffer) at log4net.Appender.BufferingAppenderSkeleton.OnClose() in c:\OSS\log4net\src\Appender\BufferingAppenderSkeleton.cs:line 411 at log4net.Appender.AdoNetAppender.OnClose() in c:\OSS\log4net\src\Appender\AdoNetAppender.cs:line 433 at log4net.Appender.AppenderSkeleton.Close() in c:\OSS\log4net\src\Appender\AppenderSkeleton.cs:line 243 at log4net.Appender.AppenderSkeleton.Finalize() in c:\OSS\log4net\src\Appender\AppenderSkeleton.cs:line 83 which may or may not be related. I do not see this when I tell NAnt to use the .NET FX 2.0 (via Nant -t:net-2.0) - I only get the ten unit test failures I already raised in JIRA. Stefan
Re: ADO.NET Appender and FX 4.0
On 2011-08-19, Roy Chastain wrote: While, this is certainly a problem, it SHOULD not be the issue already reported, because those reports were against log4Net running on the 2.0 CLR instead of the 4.0 CLR. OK. I have done some research this morning, and have found a couple of articles suggesting fixes, but I do not yet understand the ramifications. This is all to do with a new code security model created in 4.0 and it is going to take time to understand. I should add that NAnt.exe.config contains NetFx40_LegacySecurityPolicy enabled=true/ and seems to need it. This may complicate things even further. Stefan
Re: ADO.NET Appender and FX 4.0
On 2011-08-19, Roy Chastain wrote: I have done some research this morning, and have found a couple of articles suggesting fixes, but I do not yet understand the ramifications. This is all to do with a new code security model created in 4.0 and it is going to take time to understand. If anyone reading this is a 4.0 code security model guru, then please look at http://connect.microsoft.com/VisualStudio/feedback/details/464751/inheri tance-security-rules-violated-while-overriding-member and throw out an opinion. The other solution seems to involve marking the calling code, but I have not figured it all out as yet. The first two patches attached to LOG4NET-233 contain .NET 4.0 specific attributes (and even remove some of the 2.0 code base when compiling under .NET 4.0). I'm no security model guru at all and will have some reading up to do, but this may provide a starting point. Stefan
