logging-log4net-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy Chastain" <...@roychastain.org>
Subject RE: Client Profiles
Date Mon, 15 Aug 2011 19:25:46 GMT
>> I think csc is smart enough to drop references that aren't actually
Apparently not.  Below is text from the announcement of the 3.5 client
profile at
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?


View raw message