You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4net-dev@logging.apache.org by Dominik Psenner <dp...@gmail.com> on 2011/08/13 12:56:28 UTC
Open issues for 1.2.10 release
There are 9 open issues targeted for 1.2.10. They should probably be
rescheduled to be included in 1.2.11?
This list includes:
* LOG4NET-285
* LOG4NET-274
* LOG4NET-227
* LOG4NET-221
* LOG4NET-211
* LOG4NET-258
* LOG4NET-235
* LOG4NET-236
* LOG4NET-237
Please discuss.
--
Dominik Psenner
## OpenPGP Key Signature #################################
# Key ID: B469318C #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C #
##########################################################
Re: Open issues for 1.2.10 release
Posted by Stefan Bodewig <bo...@apache.org>.
On 2011-08-13, Dominik Psenner wrote:
> There are 9 open issues targeted for 1.2.10. They should probably be
> rescheduled to be included in 1.2.11?
I've just been granted enough JIRA karma to at least re-assign those
issues to 1.2.11 (but can't create new versions, yet).
Without even reading the issues I've bulk-scheduled them to 1.2.11 for
now.
Stefan
RE: Client Profiles
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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 #
##########################################################
Re: Client Profiles
Posted by 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 (was Re: Open issues for 1.2.10 release)
Posted by Dominik Psenner <dp...@gmail.com>.
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 #
##########################################################
Re: Client Profiles
Posted by Stefan Bodewig <bo...@apache.org>.
On 2011-08-15, Roy Chastain wrote:
> Let me start at some basics just to ensure that we are starting at the
> same point.
> There are 3 CLR versions, 1.x, 2.0, 4.0. Framework 3.0 and 3.5 are
> simply add on assemblies that target the 2.0 runtime. This fact is why
> the 3.5, 3.0 and 2.0 interop works so well. That is also why the
> service pack for 3.5 updates the 3.0 and 2.0 assemblies.
> 4.0 targeted runtime can call into 2.0 CLR code. The problem is that
> both the 4.0 and 2.0 CLR must be present on the system.
I knew so much, but thank you anyway - I'd likely have needed way more
words.
> This leads to a distribution package that may need to install both the
> 3.5 SP1 (the best way to get a 2.0 Framework installed) and the 4.0
> frameworks.
This is what I didn't know. My development machine doesn't list any
framework other than 4.0 as installed but still I can use the log4net
assembly that targets 2.0. Probably the installation of VS installed
the older frameworks. Anyway, for some reason I was under the
impression the 4.0 framework install would contain the 2.0 CLR.
> The dual framework package is not much of issue for Windows 7 systems,
> because Win 7 and Server 2008 r2 come with a completely patched 3.5
> framework.
OK, my case - and the production envs are either old Win 2003 servers
that used to have 2.0 installed before adding 4.0 or Win 2008 server,
this explains why we have never seen any issues.
> We need/must have a 4.0 targeted assembly (someday soon - not today) so
> that applications that are built against 4.0 will only require 4.0 and
> not 3.5 and the rest of the 2.0 CLR.
This should actually be doable for 1.2.11 with the latest NAnt alpha,
I'll see to it.
> We must also have assemblies that target both the full and client
> frameworks of 4.0 and (I believe lessor priority) 3.5 (again a polling
> question).
Yes, I agree by now.
> The second set of traffic is that "log4Net does not log anything when I
> call it for code compiled for .NET Framework 4.0". When asked, the
> response has usually been that they were attempting to use an ADO
> appender. I know the rolling file, SMTP and console appenders all work
> correctly, but I have never tried an ADO appender on any version.
Same here.
> I have just uncovered and am in the process of having Microsoft look
> at an issue in the 4.0 to 3.5 interop. In my application that uses
> both, the 4.0 code runs just fine, but when it is attempts to call the
> 3.5 code it gets an untrapped but ignored exception. This happens on
> a clean install of 3.5 SP1 and 4.0 on a clean XP system. The
> interesting thing is that a system restart resolves the issue and the
> application then runs.
Ouch.
>>> And then we add conditional compilation on a CLIENT_PROFILE that
>>> removes all System.Web references 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?
> Assuming that the reference to the missing assembly is dropped as you
> suggested, I will agree to the 3.5 client profile. (I am not saying
> that it is not dropped, I just do not have knowledge of that one way
> or the other.) An application targeting the 4.0 client profile will
> still require the install of the 3.5 client profile if we do not
> target 4.0 during the build of the assemblies.
Let me try some things with NAnt, I'm pretty confident we'll be able to
create assemblies targeting both client profiles in time for the 1.2.11
release as well.
Stefan
RE: Client Profiles
Posted by Roy Chastain <Ro...@roychastain.org>.
Sorry, I probably did not express my points well.
Let me start at some basics just to ensure that we are starting at the
same point.
There are 3 CLR versions, 1.x, 2.0, 4.0. Framework 3.0 and 3.5 are
simply add on assemblies that target the 2.0 runtime. This fact is why
the 3.5, 3.0 and 2.0 interop works so well. That is also why the
service pack for 3.5 updates the 3.0 and 2.0 assemblies.
4.0 targeted runtime can call into 2.0 CLR code. The problem is that
both the 4.0 and 2.0 CLR must be present on the system. This leads to a
distribution package that may need to install both the 3.5 SP1 (the best
way to get a 2.0 Framework installed) and the 4.0 frameworks. (I have
one of those distributions right now.) Even once the 3.5 SP1 package
that is "provided" by the SDK install is installed, there is still the
".NET Framework Family Update..." package that is only available via
Windows/Microsoft Update. (This update fails on many older somewhat
corrupted XP systems.) If a developer needs to release this update with
their install package, they would have to build package files for 3
different hotfixes (one for 2.0, 3.0 and 3.5) and for, I think, 4 (maybe
even more) different OS combinations. .
The dual framework package is not much of issue for Windows 7 systems,
because Win 7 and Server 2008 r2 come with a completely patched 3.5
framework. However, Windows XP, Vista, Server 2003 and 2008 do not come
with a 3.5 framework and therefore it MAY need to be installed.
We need/must have a 4.0 targeted assembly (someday soon - not today) so
that applications that are built against 4.0 will only require 4.0 and
not 3.5 and the rest of the 2.0 CLR.
We must also have assemblies that target both the full and client
frameworks of 4.0 and (I believe lessor priority) 3.5 (again a polling
question).
It is my contention that many of the users of log4Net have no idea about
the inoperability of the CLRs and that 4.0 can consume 2.0 targeted
code. I believe this because of the number of questions that start
along the lines of, "I cannot find the 4.0 version of log4Net, how can I
use it in xxxxx". Someone then explains to them that it will just work.
Unfortunately, the response never says that they need both frameworks
installed on the target system.
The second set of traffic is that "log4Net does not log anything when I
call it for code compiled for .NET Framework 4.0". When asked, the
response has usually been that they were attempting to use an ADO
appender. I know the rolling file, SMTP and console appenders all work
correctly, but I have never tried an ADO appender on any version. I
have just uncovered and am in the process of having Microsoft look at an
issue in the 4.0 to 3.5 interop. In my application that uses both, the
4.0 code runs just fine, but when it is attempts to call the 3.5 code it
gets an untrapped but ignored exception. This happens on a clean
install of 3.5 SP1 and 4.0 on a clean XP system. The interesting thing
is that a system restart resolves the issue and the application then
runs. (Please note that the install sequence is 3.5 SP1 followed by 4.0
followed by a system restart followed by the application. Another
restart must be done after the application is installed.) While this is
not our problem, it does raise yet more obstacles to interoping a 2.0
targeted assembly with a 4.0 targeted application.
>> And then we add conditional compilation on a CLIENT_PROFILE that
removes all System.Web
>> references 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?
Assuming that the reference to the missing assembly is dropped as you
suggested, I will agree to the 3.5 client profile. (I am not saying that
it is not dropped, I just do not have knowledge of that one way or the
other.) An application targeting the 4.0 client profile will still
require the install of the 3.5 client profile if we do not target 4.0
during the build of the assemblies.
----------------------------------------------------------------------
Roy Chastain
-----Original Message-----
From: Stefan Bodewig [mailto:bodewig@apache.org]
Sent: Monday, August 15, 2011 09:00
To: log4net-dev@logging.apache.org
Subject: Re: Client Profiles
On 2011-08-15, Roy Chastain wrote:
>>> 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.
In this case we should investigate this. It should stick out when
triaging JIRAs.
> 2) - We certainly need code that will compile against the 4.0
Framework.
Against 2.0, no?
> 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'm sure I know what you are talking about.
Stefan
Re: Client Profiles
Posted by Stefan Bodewig <bo...@apache.org>.
On 2011-08-15, Roy Chastain wrote:
>>> 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.
In this case we should investigate this. It should stick out when
triaging JIRAs.
> 2) - We certainly need code that will compile against the 4.0 Framework.
Against 2.0, no?
> 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'm sure I know what you are talking about.
Stefan
RE: Client Profiles (was Re: Open issues for 1.2.10 release)
Posted by Roy Chastain <Ro...@roychastain.org>.
>> 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:bodewig@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
Client Profiles (was Re: Open issues for 1.2.10 release)
Posted by Stefan Bodewig <bo...@apache.org>.
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: Open issues for 1.2.10 release
Posted by Dominik Psenner <dp...@gmail.com>.
On 08/13/2011 04:46 PM, Stefan Bodewig wrote:
> I'm not even sure whether some of them still are relevant. They
> certainly need to be rescheduled.
>
> My preference would be to have some release like 1.2.MAINTNENANCE that
> we'd assign things to that may eventually get fixed in a 1.2.x release
> if we agree that these are the versions that actually work for compact
> framework and 1.x - and a few others similar unspecific releases.
>
> We then pick the pieces from there as we prepare real releases.
>
> Right now I'm afraid we'll have to visit all open issues and
> re-assign/close them.
Its a lot of work, but it has to be done. We're then able to identify
(really) open bugs and we can then see forward to resolve them for 1.2.11.
Further there are a lot of changesets (101) that are still waiting to be
included in the next release. We probably have to work through them too.
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
We have to investigate into all this a little more so that we can come
up with a plan that just works.
--
Dominik Psenner
## OpenPGP Key Signature #################################
# Key ID: B469318C #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C #
##########################################################
Re: Open issues for 1.2.10 release
Posted by Stefan Bodewig <bo...@apache.org>.
On 2011-08-13, Dominik Psenner wrote:
> There are 9 open issues targeted for 1.2.10. They should probably be
> rescheduled to be included in 1.2.11?
I'm not even sure whether some of them still are relevant. They
certainly need to be rescheduled.
My preference would be to have some release like 1.2.MAINTNENANCE that
we'd assign things to that may eventually get fixed in a 1.2.x release
if we agree that these are the versions that actually work for compact
framework and 1.x - and a few others similar unspecific releases.
We then pick the pieces from there as we prepare real releases.
Right now I'm afraid we'll have to visit all open issues and
re-assign/close them.
Stefan