>> 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:bode...@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
