A couple of issues 1) - There is no client profile for 2.0. 3.5 is the first version with a client profile. 2) - There is more to building against client profiles than removing namespaces. The references must be changed to remove the Framework DLLs that are not part of the client profile. Again, I don't know the tool, NAnt. Can it do that?
3) - (This probably should be in the 4.0 discussion, but it is related here too.) When you retarget a project to 4.0 (or back to 3.5) VS changes the references. Some of the namespaces and classes have been placed in different assemblies etc. It COULD be more difficult than just retargeting and, I think, this issue may further push to releasing a 4.0 targeted assembly. Again, the issue is adding/removing references. Even if none of the referenced assemblies change names, the different versions of them must be targeted during the builds. ---------------------------------------------------------------------- Roy Chastain -----Original Message----- From: Stefan Bodewig [mailto:bode...@apache.org] Sent: Monday, August 15, 2011 06:15 To: log4net-dev@logging.apache.org Subject: Re: Client Profiles On 2011-08-15, Dominik Psenner wrote: > On 08/15/2011 11:26 AM, Stefan Bodewig wrote: >> Like I said later, I'm not convinced we need to target 4.0 at all as >> the >> 2.0 version should just work. For client profile we could use a >> stripped down 2.0 version or explicitly target 3.5 (client profile). >> But I may very well be missing some nuance. > You once asked if VS2010 can change the target profile. I know that my Premium Edition can, I was asking about the no-cost editions (Express or whatver they are called for 2010 this time). >> We don't have any (working) CI for log4net right now. The only one >> I'm aware of is Gump and this one only builds the Mono parts so isn't >> really useful. It doesn't perform any tests either. > Now that you say it. I just ran nant from my ubuntu laptop and was > impressed that it went through without complains. :-) I just built > log4net for mono 1.0 and 2.0. *laughing* I'm going to copy that dll to > my windows pc and see if I can use it across different projects (2.0, > 3.0, 3.5, 4.0, 3.5CP, 4.0CP) and report the results. Works reasonably well in my experience, I know I've done so in the past. the same is true for the other direction, that's why I doubt we need specific Mono assemblies. >> Jenkins - one option available from ci.apache.org - does support >> MSBuild (on Windows, of course) and likely NAnt as well. I know the >> Lucene.NET project is looking for CI builds so the infrstructure for >> "real" .NET builds should be there at one point. > Where did you read up jenkins? Ah, the ci.apache.org site still says Hudson and hasn't followed the hostname changes we did when we switched from Hudon to Jenkins. /me takes note to bug infra. <https://builds.apache.org/> is our Jenkins farm which also contains a Windows 2008 Server instance. The Chemistry build likely already uses MSBuild (yes, looks like the 3.5 version). > Btw, why does the nant build only produce mono files? No, it doesn't do that at all. I've built .NET 2.0 and 3.5 DLLs using NAnt 0.90 with my installation on Win7 just fine. The one running in Gump can't produce any other as Gump is running on Linux (and some other OSes with no kind of .NET support installed at all). Stefan
