Client Profiles (was Re: Open issues for 1.2.10 release)
On 2011-08-15, Dominik Psenner wrote: The other big story is the support for the .NET client profiles. As I understood it, we have to drop everything in log4net that is not supported in a .NET 4.0 client profile (i.e. references to System.Web). To achieve this we have at least two options: 1] refactor everything that doesn't fit with the client profile into a separate project / dll 2] maintain a .net 4.0 client profile branch with a subset of the log4net functionality * Solution [1] is a pain for everyone that uses log4net since they need to reference two libraries instead of one * Solution [2] is a pain to maintain with subversion Not really, solution 2 doesn't require a branch IMHO. Right now the NAnt build builds several different assemblies targeting different platforms all out of the same source tree and it should be straight forward to extend that to the client profile as well. Tasos' patch basically works the same way as log4net supports the compact framework now - it adds a conditional compilation symbol and simply excludes all System.Web stuff if that is set. We could extend the NAnt build to create even more assemblies (4.0 had to be added and 3.5 client profile as well as 4.0 client profile), set the CLIENT_PROFILE symbol and be done. This should even be possible for 1.2.11 - at the expense of even more assemblies. The main hurdle may be NAnt's limited support for .NET 4.0 (need to use a nightly build for now) and I don't think there is a target defintion for client profiles at all - but that should be doable. I'm willing to invest some effort here. Longer term switching to MSBuild or the solution task in NAnt and using Visual Studio 2010 solution files targeting the correct platform may work should we plan to drop support form 1.x, Compact Framework and explicit support for Mono. What I wonder is: do we really need 3.5 and 4.0 assemblies at all? Wouldn't a 2.0 assembly including System.Web and a 3.5 client profile assembly without it work for .NET 3.5/4.0 projects and and their client profile subsets well enough? For 1.2.11 that is, later we may want to use LINQ or WCF or whatever. Stefan
Re: Client Profiles (was Re: Open issues for 1.2.10 release)
On 08/15/2011 08:29 AM, Stefan Bodewig wrote: Right now the NAnt build builds several different assemblies targeting different platforms all out of the same source tree and it should be straight forward to extend that to the client profile as well. Tasos' patch basically works the same way as log4net supports the compact framework now - it adds a conditional compilation symbol and simply excludes all System.Web stuff if that is set. I get the idea. Until now I didn't understand how log4net was built at all. If it works, it's fine by me. :-) The main hurdle may be NAnt's limited support for .NET 4.0 (need to use a nightly build for now) and I don't think there is a target defintion for client profiles at all - but that should be doable. I'm willing to invest some effort here. What I've read so far, NAnt 0.91 alpha 2 supports .NET 4.0. At least that's what they're writing in that table on their frontpage (http://nant.sourceforge.net/). Does that help us? Longer term switching to MSBuild or the solution task in NAnt and using Visual Studio 2010 solution files targeting the correct platform may work should we plan to drop support form 1.x, Compact Framework and explicit support for Mono. I would favorise that, but I don't know if that's possible with ASFs continuous integration. What I wonder is: do we really need 3.5 and 4.0 assemblies at all? Wouldn't a 2.0 assembly including System.Web and a 3.5 client profile assembly without it work for .NET 3.5/4.0 projects and and their client profile subsets well enough? For 1.2.11 that is, later we may want to use LINQ or WCF or whatever. Yes, it should. That's also one thing I wanted to try. If MSbuild can produce something that works for .NET 3.5/4.0 client profile and .NET 4.0 we may be able to reproduce it with NAnt. Otherwise we don't even have to try, do we? -- Dominik Psenner ## OpenPGP Key Signature # # Key ID: B469318C # # Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C # ## signature.asc Description: OpenPGP digital signature
RE: Client Profiles (was Re: Open issues for 1.2.10 release)
What I wonder is: do we really need 3.5 and 4.0 assemblies at all? Two comments 1) - There seems to be a lot of confusion among developers about the Frameworks. By reading the questions that have been asked on the list, I believe that many of them do not realize that a 4.0 framework app can call 3.5 framework code. It is not necessarily our job to educate them, but there has been a lot of traffic about 4.0 and even numerous bug reports about failures. I do not believe I ever saw a real description of the failure, but it seems that several of them dealt with ADO appenders, so there could actually be a problem with them. 2) - We certainly need code that will compile against the 4.0 Framework. I currently have a product that requires 4.0 and 3.5 and the amount of time to install it on an out of date XP system is absurd. We all think XP should be gone, but the reality is that it is not. Same for sever 2003. I think we should produce the assemblies because of the 3rd party apps. -- Roy Chastain -Original Message- From: Stefan Bodewig [mailto:bode...@apache.org] Sent: Monday, August 15, 2011 02:29 To: log4net-dev@logging.apache.org Subject: Client Profiles (was Re: Open issues for 1.2.10 release) On 2011-08-15, Dominik Psenner wrote: The other big story is the support for the .NET client profiles. As I understood it, we have to drop everything in log4net that is not supported in a .NET 4.0 client profile (i.e. references to System.Web). To achieve this we have at least two options: 1] refactor everything that doesn't fit with the client profile into a separate project / dll 2] maintain a .net 4.0 client profile branch with a subset of the log4net functionality * Solution [1] is a pain for everyone that uses log4net since they need to reference two libraries instead of one * Solution [2] is a pain to maintain with subversion Not really, solution 2 doesn't require a branch IMHO. Right now the NAnt build builds several different assemblies targeting different platforms all out of the same source tree and it should be straight forward to extend that to the client profile as well. Tasos' patch basically works the same way as log4net supports the compact framework now - it adds a conditional compilation symbol and simply excludes all System.Web stuff if that is set. We could extend the NAnt build to create even more assemblies (4.0 had to be added and 3.5 client profile as well as 4.0 client profile), set the CLIENT_PROFILE symbol and be done. This should even be possible for 1.2.11 - at the expense of even more assemblies. The main hurdle may be NAnt's limited support for .NET 4.0 (need to use a nightly build for now) and I don't think there is a target defintion for client profiles at all - but that should be doable. I'm willing to invest some effort here. Longer term switching to MSBuild or the solution task in NAnt and using Visual Studio 2010 solution files targeting the correct platform may work should we plan to drop support form 1.x, Compact Framework and explicit support for Mono. What I wonder is: do we really need 3.5 and 4.0 assemblies at all? Wouldn't a 2.0 assembly including System.Web and a 3.5 client profile assembly without it work for .NET 3.5/4.0 projects and and their client profile subsets well enough? For 1.2.11 that is, later we may want to use LINQ or WCF or whatever. Stefan
