Re: State of Client Profile and .NET 4.0 Support
On 2011-09-04, Stefan Bodewig wrote: > On 2011-08-25, Ron Grabowski wrote: >> Is your .NET 4 support just in the NAnt scripts? > Yes, exclusively. >> It's probably safe to replace the VS2008 solution file with a VS2010 >> version. > I didn't go that far because my VS insisted on converting the project > files as There now is a VS2010 solution (and corresponding project files for log4net and the tests) that target .NET 4.0 and set the proper compilation symbols. I could have done the same for client profile builds but felt I'd promise to maintain them if I did - and right now I don't really plan to actively maintain any of the VS projects/solutions. Stefan
Re: State of Client Profile and .NET 4.0 Support
Hi Ron, good to hear from you. On 2011-08-25, Ron Grabowski wrote: > Is your .NET 4 support just in the NAnt scripts? Yes, exclusively. > It's probably safe to replace the VS2008 solution file with a VS2010 > version. I didn't go that far because my VS insisted on converting the project files as well. At least one of the several JIRA issues contains attached solution files, one for 4.0 and one for 4.0 Client Profile. Stefan
Re: State of Client Profile and .NET 4.0 Support
Is your .NET 4 support just in the NAnt scripts? It's probably safe to replace the VS2008 solution file with a VS2010 version. From: Stefan Bodewig To: log4net-dev@logging.apache.org Sent: Saturday, August 20, 2011 6:14 AM Subject: State of Client Profile and .NET 4.0 Support Hi all, I've hacked in client profile support - the NAnt build files are becoming a bigger mess of copy-paste with each change, but this is a different story. I've taken Tasos' approach and defined a CLIENT_PROFILE compilation symbol and conditionally excluded the ASP.NET stuff if it is present and in addition NAnt won't reference System.Web. I haven't performed any extensive testing but at least I was able to build a minimal client profile command line app and write a log message to a file using the 3.5 Client Profile assembly created (which in reality is a 2.0 Client Profile assembly). For 4.0 this doesn't work, but it is not due to Client Profile but to the security related exception I already raised in a different thread. As soon as I try to load any type from any of the two assemblies targeting 4.0 a TypeLoadException is raised because of Inheritance security rules violated while overriding member: 'log4net.Util.ReadOnlyPropertiesDictionary.GetObjectData(System.Runtime.Serialization.SerializationInfo, System.Runtime.Serialization.StreamingContext)'. Security accessibility of the overriding method must match the security accessibility of the method being overriden. log4net.Util.ReadOnlyPropertiesDictionary.GetObjectData(System.Runtime.Serialization.SerializationInfo, System.Runtime.Serialization.StreamingContext)"} So this isn't related to ADO.NET as I suspected in the other thread. Of the three patches attached to LOG4NET-233 two contain security related attributes in the 4.0 case - but they take different approaches. I'll have to read up on the differences of the security models and the ramifications of either approach before deciding what to do. I can't promise this will happen this weekend (rather unlikely). Any advice from people with more (should I say any?) knowledge is welcome 8-) Stefan
State of Client Profile and .NET 4.0 Support
Hi all, I've hacked in client profile support - the NAnt build files are becoming a bigger mess of copy-paste with each change, but this is a different story. I've taken Tasos' approach and defined a CLIENT_PROFILE compilation symbol and conditionally excluded the ASP.NET stuff if it is present and in addition NAnt won't reference System.Web. I haven't performed any extensive testing but at least I was able to build a minimal client profile command line app and write a log message to a file using the 3.5 Client Profile assembly created (which in reality is a 2.0 Client Profile assembly). For 4.0 this doesn't work, but it is not due to Client Profile but to the security related exception I already raised in a different thread. As soon as I try to load any type from any of the two assemblies targeting 4.0 a TypeLoadException is raised because of Inheritance security rules violated while overriding member: 'log4net.Util.ReadOnlyPropertiesDictionary.GetObjectData(System.Runtime.Serialization.SerializationInfo, System.Runtime.Serialization.StreamingContext)'. Security accessibility of the overriding method must match the security accessibility of the method being overriden. log4net.Util.ReadOnlyPropertiesDictionary.GetObjectData(System.Runtime.Serialization.SerializationInfo, System.Runtime.Serialization.StreamingContext)"} So this isn't related to ADO.NET as I suspected in the other thread. Of the three patches attached to LOG4NET-233 two contain security related attributes in the 4.0 case - but they take different approaches. I'll have to read up on the differences of the security models and the ramifications of either approach before deciding what to do. I can't promise this will happen this weekend (rather unlikely). Any advice from people with more (should I say any?) knowledge is welcome 8-) Stefan