Re: Client Profiles

[Stefan Bodewig <bo...@apache.org>]

On 2011-08-15, Dominik Psenner wrote:

> 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/).

That's what they say, yes. 8-)

> Does that help us?

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.

>> 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.

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.

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.

Stefan

RE: Client Profiles

[Roy Chastain <Ro...@roychastain.org>]

>> I think csc is smart enough to drop references that aren't actually
used.  
Apparently not.  Below is text from the announcement of the 3.5 client
profile at
http://blogs.windowsclient.net/trickster92/archive/2008/05/21/introducin
g-the-net-framework-client-profile.aspx.  I draw you attention to the
last sentence of the second paragraph.


Checking this option will update the project in two ways. First, the
compiler will check the project's assembly references against a list of
Client Framework Assemblies to see if there are any conflicts. If your
project references assemblies that are not in the Client Framework
Assemblies list, it will show up as a compilation warning. 

Developers will need to be aware of this compilation warning and make
the appropriate changes to their project in order to function properly
on the Client Profile. If this is not done, applications may see random
MethodNotFoundException error messages or their applications may not
function properly at all.

----------------------------------------------------------------------
Roy Chastain




-----Original Message-----
From: Stefan Bodewig [mailto:bodewig@apache.org] 
Sent: Monday, August 15, 2011 08:57
To: log4net-dev@logging.apache.org
Subject: Re: Client Profiles

On 2011-08-15, Roy Chastain wrote:

> 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.

I understand both of those points.

Let's assume we target 2.0 and nothing else and create the current
assembly.  This should work for 3.5 and 4.0 just fine, doesnt it?  I've
been using such a setup in production for months if not years (the 3.5
case) now and never saw any problems.  We are not using any of the more
fancy appenders, though.

And then we add conditional compilation on a CLIENT_PROFILE that removes
all System.Web referenes and target 2.0 again but this time with the
symbol set.  Shouldn't the resulting assembly work for the 3.5 and 4.0
client profiles?

> 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?

I think csc is smart enough to drop references that aren't actually
used.  In theory NAnt can ensure we don't reference anything that
shouldn't be there but this is where it needs configuartion for the
target and I don't think there currently exist configurations for the
client profiles.

> 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.

OK.  But this really only comes up once we try to build for the 3.5 and
4.0 targets explicitly.  As long as we don't use anything that's not
part of 2.0 then we don't have to do that, do we?

Stefan

Re: Client Profiles

[Stefan Bodewig <bo...@apache.org>]

On 2011-08-15, Roy Chastain wrote:

> 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.

I understand both of those points.

Let's assume we target 2.0 and nothing else and create the current
assembly.  This should work for 3.5 and 4.0 just fine, doesnt it?  I've
been using such a setup in production for months if not years (the 3.5
case) now and never saw any problems.  We are not using any of the more
fancy appenders, though.

And then we add conditional compilation on a CLIENT_PROFILE that removes
all System.Web referenes and target 2.0 again but this time with the
symbol set.  Shouldn't the resulting assembly work for the 3.5 and 4.0
client profiles?

> 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?

I think csc is smart enough to drop references that aren't actually
used.  In theory NAnt can ensure we don't reference anything that
shouldn't be there but this is where it needs configuartion for the
target and I don't think there currently exist configurations for the
client profiles.

> 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.

OK.  But this really only comes up once we try to build for the 3.5 and
4.0 targets explicitly.  As long as we don't use anything that's not
part of 2.0 then we don't have to do that, do we?

Stefan

RE: Client Profiles

[Roy Chastain <Ro...@roychastain.org>]

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:bodewig@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

Re: Client Profiles

[Stefan Bodewig <bo...@apache.org>]

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

Re: Client Profiles

[Dominik Psenner <dp...@gmail.com>]

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. Yes, it can. I
did it at work some time. But unfortunatly it is something that defines
a projects dependencies. So it is not something that can simply be
changed by a built tool. In VS2010 you have to configure the project to
be targeted for a specific .NET framework and VS makes sure the project
finds the correct libraries.

> 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.

*ouch*

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.

> 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? There's continuum and buildbot. The
latter runs on a win7 machine and therefore could be able to run msbuild.

Btw, why does the nant build only produce mono files?
-- 
Dominik Psenner
## OpenPGP Key Signature #################################
# Key ID: B469318C                                       #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C  #
##########################################################