RE: Thoughts on 1.3
Sorry about that. I've been slow scanning through my emails. -Oorspronkelijk bericht- Van: "Dominik Psenner" Verzonden: 6/02/2014 8:07 Aan: "'Log4NET Dev'" Onderwerp: AW: Thoughts on 1.3 That's exactly what I had pointed out in the original thread. :-) >-Ursprüngliche Nachricht- >Von: gert.drie...@telenet.be [mailto:gert.drie...@telenet.be] >Gesendet: Mittwoch, 5. Februar 2014 22:15 >An: Log4NET Dev >Betreff: Re: Thoughts on 1.3 > >Hey Miljenko, > >I don't think it makes sense to create a separate "client-profile" version. >MS has already abandoned this: >http://msdn.microsoft.com/en-us/library/cc656912(v=vs.110).aspx > >Perhaps you were referring to a portable class library ? > >Cheers, >Gert > >- Oorspronkelijk bericht - >Van: "Miljenko Cvjetko" >Aan: "Log4NET Dev" >Verzonden: Dinsdag 4 februari 2014 14:44:00 >Onderwerp: Re: Thoughts on 1.3 > >Hi > >On 2014.02.04 13:24, w...@poczta.fm wrote: >> Hi >> >> If You work on port of log4net to Xamarin You may find helpful the patch >attached to LOG4NET-338 "Port of log4net for MonoDroid" >(https://issues.apache.org/jira/browse/LOG4NET-338). >I saw Your patch after I was finished. AndroidAppender was almost the same. >> My port does not change the structure of the library however some parts >may still work for You. >I was b bit more "radical" and intrusive, so I split the lib into client >profile and non-client profile. > >pozdrawiam > >Mel >> >> Regards >> Wojciech Dec >> >> >> Od: "Miljenko Cvjetko" >> Do: log4net-dev@logging.apache.org; >> Wysłane: 15:47 Poniedziałek 2014-02-03 >> Temat: Thoughts on 1.3 >> >>> Hi >>> >>> I have tried to post this one through the nabble on Nov 25th and 26th. >>> My post are still there as "not accepted". Then I got dragged away with >>> projects, then holidays and again projects. Now I have a bit easier, so >>> I’d like to add few thoughts. >>> >>> My name is Miljenko Cvjetko and I'm the one that forked log4net on >>> GitHub, did some structural changes on the solution/project in order to >>> "port" it to Xamarin Mobile profiles (Xamarin.iOS and Xamarin.Android) >>> and contacted Stefan for a permission to submit log4net Xamarin >>> Component to Xamarin Componet Store. >>> >>> Stefan asked me whether I can put some thoughts and more light on the >>> subject in this thread about the Version 1.3. >>> >>> There were several questions both on mailing-lists and forums about >>> availability of the log4net for Mono Mobile profiles (Xamarin Mobile) >>> and I was personally faced with that issue when our team worked on >>> Application that uses mobile port of SharpSNMP, which uses log4net. The >>> quick and dirty workaround was to exclude the dependency (and >comment it >>> out). >>> >>> The era of mobile enterprise apps is about to begin and a lot of code >>> will be ported from desktop and server side (ASP.net) to mobile in order >>> to reuse code. Almost all utilities/libraries/tools for .net have >>> disadvantage/handicap that they are written for desktop and/or ASP.net, >>> thus using APIs and/or concepts that are not acceptable or possible on >>> mobile devices. To name some: System.Web assembly (used by log4net) >and >>> Configuration utilities which need Xml support. >>> >>> What I actually did is simply split log4net into 2 assemblies, the one >>> with client profile called log4net.client and the other with only >>> ASP.net specific stuff with old name log4net. The code was >>> source-linked, so log4net was for external usage the same as it used to be. >>> >>> All unit tests passed w/o problems. >>> >>> So I would suggest You to do as Stefan suggested: >>> >>> 1. "to split log4net-13.dll so that the main assembly can be used for >>> the client profile and a separate assembly contains the stuff that >>> requires System.Web - this way we no longer need the -cp builds." >>> >>> 2. add separate assemblies for async/await (netfx 4.5, mono 3.x), so >>> people are not forced into 4.5. >>> >>> I have worked with log4net on Xamarin's alpha channel for last 2 months >>> and experienced no problems only stuff I would suggest to add async >>> wrappers (suggestion 2.). >>> >>> Also Stefan asked me to merge
AW: Thoughts on 1.3
While we separate the library we require everyone – not just the mobiles – to add a new reference, adapt deployments, etc. Whereas the mobile people could update their requirements by targeting their application to .NET 4.5. So the question is: do we really want to break backwards compatibility to help fresh ASP.NET applications that could also retarget to the .NET framework 4.5? Talking for myself this is not as sensible as it may seems like at first glance. Von: Miljenko Cvjetko [mailto:mcvje...@holisticware.net] Gesendet: Donnerstag, 6. Februar 2014 10:03 An: log4net-dev@logging.apache.org Betreff: Re: Thoughts on 1.3 Hi Gert On 2014.02.05 22:14, gert.drie...@telenet.be <mailto:gert.drie...@telenet.be> wrote: Hey Miljenko, I don't think it makes sense to create a separate "client-profile" version. MS has already abandoned this: http://msdn.microsoft.com/en-us/library/cc656912(v=vs.110).aspx I'm aware of that. Maybe the term "client-profile" was unfortunate. Let's call it "System.Web.dll-less" or "ASP.net-less". I'm aware that log4net origins are more on the server side and that eventually came down to desktops and this journey continues toward mobile right now. This is the problem of most libraries and no one is to be blamed. It is simply how technologies came in and mobile came as last. Ideal would be to write mobile first, but this cannot be done. Perhaps you were referring to a portable class library ? No. I did not "Separating "client-profile"" means just trimming down the parts not needed on desktop and mobile. Steps I suggested: 1. extracting ASP.net (System.Web.dll) dependencies for all clients 2. extracting System.Configuration.dll for mobile I didn't do that in first version 2013-10, but would like to do in next run For more info read JonP's part of this discussion: <http://forums.xamarin.com/discussion/3300/rationale-behind-removal-of-system-diagnostics-trace-in-xa-and-xi#latest> http://forums.xamarin.com/discussion/3300/rationale-behind-removal-of-system-diagnostics-trace-in-xa-and-xi#latest 3. this leaves "common" stuff today I would put it into PCL, but 3-6 months PCLs were not ideal (more problems than benefits) I usually created dll/assembly per platform and source was linked from one of those into other. Cheers, Gert Best regards Mel
Re: Thoughts on 1.3
Hi Gert On 2014.02.05 22:14, gert.drie...@telenet.be wrote: Hey Miljenko, I don't think it makes sense to create a separate "client-profile" version. MS has already abandoned this: http://msdn.microsoft.com/en-us/library/cc656912(v=vs.110).aspx I'm aware of that. Maybe the term "client-profile" was unfortunate. Let's call it "System.Web.dll-less" or "ASP.net-less". I'm aware that log4net origins are more on the server side and that eventually came down to desktops and this journey continues toward mobile right now. This is the problem of most libraries and no one is to be blamed. It is simply how technologies came in and mobile came as last. Ideal would be to write mobile first, but this cannot be done. Perhaps you were referring to a portable class library ? No. I did not "Separating "client-profile"" means just trimming down the parts not needed on desktop and mobile. Steps I suggested: 1. extracting ASP.net (System.Web.dll) dependencies for all clients 2. extracting System.Configuration.dll for mobile I didn't do that in first version 2013-10, but would like to do in next run For more info read JonP's part of this discussion: http://forums.xamarin.com/discussion/3300/rationale-behind-removal-of-system-diagnostics-trace-in-xa-and-xi#latest 3. this leaves "common" stuff today I would put it into PCL, but 3-6 months PCLs were not ideal (more problems than benefits) I usually created dll/assembly per platform and source was linked from one of those into other. Cheers, Gert Best regards Mel
AW: Thoughts on 1.3
That's exactly what I had pointed out in the original thread. :-) >-Ursprüngliche Nachricht- >Von: gert.drie...@telenet.be [mailto:gert.drie...@telenet.be] >Gesendet: Mittwoch, 5. Februar 2014 22:15 >An: Log4NET Dev >Betreff: Re: Thoughts on 1.3 > >Hey Miljenko, > >I don't think it makes sense to create a separate "client-profile" version. >MS has already abandoned this: >http://msdn.microsoft.com/en-us/library/cc656912(v=vs.110).aspx > >Perhaps you were referring to a portable class library ? > >Cheers, >Gert > >- Oorspronkelijk bericht - >Van: "Miljenko Cvjetko" >Aan: "Log4NET Dev" >Verzonden: Dinsdag 4 februari 2014 14:44:00 >Onderwerp: Re: Thoughts on 1.3 > >Hi > >On 2014.02.04 13:24, w...@poczta.fm wrote: >> Hi >> >> If You work on port of log4net to Xamarin You may find helpful the patch >attached to LOG4NET-338 "Port of log4net for MonoDroid" >(https://issues.apache.org/jira/browse/LOG4NET-338). >I saw Your patch after I was finished. AndroidAppender was almost the same. >> My port does not change the structure of the library however some parts >may still work for You. >I was b bit more "radical" and intrusive, so I split the lib into client >profile and non-client profile. > >pozdrawiam > >Mel >> >> Regards >> Wojciech Dec >> >> >> Od: "Miljenko Cvjetko" >> Do: log4net-dev@logging.apache.org; >> Wysłane: 15:47 Poniedziałek 2014-02-03 >> Temat: Thoughts on 1.3 >> >>> Hi >>> >>> I have tried to post this one through the nabble on Nov 25th and 26th. >>> My post are still there as "not accepted". Then I got dragged away with >>> projects, then holidays and again projects. Now I have a bit easier, so >>> I’d like to add few thoughts. >>> >>> My name is Miljenko Cvjetko and I'm the one that forked log4net on >>> GitHub, did some structural changes on the solution/project in order to >>> "port" it to Xamarin Mobile profiles (Xamarin.iOS and Xamarin.Android) >>> and contacted Stefan for a permission to submit log4net Xamarin >>> Component to Xamarin Componet Store. >>> >>> Stefan asked me whether I can put some thoughts and more light on the >>> subject in this thread about the Version 1.3. >>> >>> There were several questions both on mailing-lists and forums about >>> availability of the log4net for Mono Mobile profiles (Xamarin Mobile) >>> and I was personally faced with that issue when our team worked on >>> Application that uses mobile port of SharpSNMP, which uses log4net. The >>> quick and dirty workaround was to exclude the dependency (and >comment it >>> out). >>> >>> The era of mobile enterprise apps is about to begin and a lot of code >>> will be ported from desktop and server side (ASP.net) to mobile in order >>> to reuse code. Almost all utilities/libraries/tools for .net have >>> disadvantage/handicap that they are written for desktop and/or ASP.net, >>> thus using APIs and/or concepts that are not acceptable or possible on >>> mobile devices. To name some: System.Web assembly (used by log4net) >and >>> Configuration utilities which need Xml support. >>> >>> What I actually did is simply split log4net into 2 assemblies, the one >>> with client profile called log4net.client and the other with only >>> ASP.net specific stuff with old name log4net. The code was >>> source-linked, so log4net was for external usage the same as it used to be. >>> >>> All unit tests passed w/o problems. >>> >>> So I would suggest You to do as Stefan suggested: >>> >>> 1. "to split log4net-13.dll so that the main assembly can be used for >>> the client profile and a separate assembly contains the stuff that >>> requires System.Web - this way we no longer need the -cp builds." >>> >>> 2. add separate assemblies for async/await (netfx 4.5, mono 3.x), so >>> people are not forced into 4.5. >>> >>> I have worked with log4net on Xamarin's alpha channel for last 2 months >>> and experienced no problems only stuff I would suggest to add async >>> wrappers (suggestion 2.). >>> >>> Also Stefan asked me to merge code into 1.2.x (1.2.13) branch, so I'll >>> do that in next few days and issue pull request as soon as I'm done. I >>> will try to be least intrusive, so will probably end up with: >>> >>&
Re: Thoughts on 1.3
Hey Miljenko, I don't think it makes sense to create a separate "client-profile" version. MS has already abandoned this: http://msdn.microsoft.com/en-us/library/cc656912(v=vs.110).aspx Perhaps you were referring to a portable class library ? Cheers, Gert - Oorspronkelijk bericht - Van: "Miljenko Cvjetko" Aan: "Log4NET Dev" Verzonden: Dinsdag 4 februari 2014 14:44:00 Onderwerp: Re: Thoughts on 1.3 Hi On 2014.02.04 13:24, w...@poczta.fm wrote: > Hi > > If You work on port of log4net to Xamarin You may find helpful the patch > attached to LOG4NET-338 "Port of log4net for MonoDroid" > (https://issues.apache.org/jira/browse/LOG4NET-338). I saw Your patch after I was finished. AndroidAppender was almost the same. > My port does not change the structure of the library however some parts may > still work for You. I was b bit more "radical" and intrusive, so I split the lib into client profile and non-client profile. pozdrawiam Mel > > Regards > Wojciech Dec > > > Od: "Miljenko Cvjetko" > Do: log4net-dev@logging.apache.org; > Wysłane: 15:47 Poniedziałek 2014-02-03 > Temat: Thoughts on 1.3 > >> Hi >> >> I have tried to post this one through the nabble on Nov 25th and 26th. >> My post are still there as "not accepted". Then I got dragged away with >> projects, then holidays and again projects. Now I have a bit easier, so >> I’d like to add few thoughts. >> >> My name is Miljenko Cvjetko and I'm the one that forked log4net on >> GitHub, did some structural changes on the solution/project in order to >> "port" it to Xamarin Mobile profiles (Xamarin.iOS and Xamarin.Android) >> and contacted Stefan for a permission to submit log4net Xamarin >> Component to Xamarin Componet Store. >> >> Stefan asked me whether I can put some thoughts and more light on the >> subject in this thread about the Version 1.3. >> >> There were several questions both on mailing-lists and forums about >> availability of the log4net for Mono Mobile profiles (Xamarin Mobile) >> and I was personally faced with that issue when our team worked on >> Application that uses mobile port of SharpSNMP, which uses log4net. The >> quick and dirty workaround was to exclude the dependency (and comment it >> out). >> >> The era of mobile enterprise apps is about to begin and a lot of code >> will be ported from desktop and server side (ASP.net) to mobile in order >> to reuse code. Almost all utilities/libraries/tools for .net have >> disadvantage/handicap that they are written for desktop and/or ASP.net, >> thus using APIs and/or concepts that are not acceptable or possible on >> mobile devices. To name some: System.Web assembly (used by log4net) and >> Configuration utilities which need Xml support. >> >> What I actually did is simply split log4net into 2 assemblies, the one >> with client profile called log4net.client and the other with only >> ASP.net specific stuff with old name log4net. The code was >> source-linked, so log4net was for external usage the same as it used to be. >> >> All unit tests passed w/o problems. >> >> So I would suggest You to do as Stefan suggested: >> >> 1. "to split log4net-13.dll so that the main assembly can be used for >> the client profile and a separate assembly contains the stuff that >> requires System.Web - this way we no longer need the -cp builds." >> >> 2. add separate assemblies for async/await (netfx 4.5, mono 3.x), so >> people are not forced into 4.5. >> >> I have worked with log4net on Xamarin's alpha channel for last 2 months >> and experienced no problems only stuff I would suggest to add async >> wrappers (suggestion 2.). >> >> Also Stefan asked me to merge code into 1.2.x (1.2.13) branch, so I'll >> do that in next few days and issue pull request as soon as I'm done. I >> will try to be least intrusive, so will probably end up with: >> >> 1. src folder with ASP.net project (dependencies), so it is the same for >> regression and backward compatibility >> 2. src-client (or whatever) with client profile - this might be even PCL >> - I have to see. >> 3. src-mobile for iOS and Android assemblies. >> >> Xamarin Component stuff will be added later on. >> >> I hope I did not bother You too much and thank You >> >> best regards >> >> Mel >> >> -- >> Miljenko Cvjetko dipl.ing. ET >> Direktor/CEO >> Projektant rješenja/Solution Architect >> Razvojni programer/Senior developer >> Voditelj projekta/Project Manager >> >> IX južna obala 13 >> Kajzerica Zagreb >> T: 385 1 777 >> M: 385 91 557 447 3 >> F: 385 1 7779556 >> e: mcvje...@holisticware.net >> w: http://holisticware.net >> >> > > -- Miljenko Cvjetko dipl.ing. ET Direktor/CEO Projektant rješenja/Solution Architect Razvojni programer/Senior developer Voditelj projekta/Project Manager IX južna obala 13 Kajzerica Zagreb T: 385 1 777 M: 385 91 557 447 3 F: 385 1 7779556 e: mcvje...@holisticware.net w: http://holisticware.net
Re: Thoughts on 1.3
On 2014-02-04, Miljenko Cvjetko wrote: > Hi >>> 1. "to split log4net-13.dll so that the main assembly can be used for >>> the client profile and a separate assembly contains the stuff that >>> requires System.Web - this way we no longer need the -cp builds." >> Dominik convinced me there was no future for the client profiles anyway, >> but back then I didn't think about mobile platforms, much less Xamarin. > It is up to You. I'm willing to help. Yes, and many thanks to that. Back when we discussed this first, I refrained from splitting the library because it didn't look worthwhile. I'm not so sure anymore. >>> Also Stefan asked me to merge code into 1.2.x (1.2.13) branch, so I'll >>> do that in next few days and issue pull request as soon as I'm done. I >>> will try to be least intrusive, so will probably end up with: >> Note current trunk has been restructured quite a lot, a lot of folders >> have been moved around and I doubt our github mirror would track that as >> proper moves. > So github mirror is not actual state of the project? > I would refork it and do all the steps again. This would be few > days. Then You could check and correct me. Honestly I don't have much of an idea. The github mirror is just a mirror and we don't even get notified of pull requests - I check the project every now and then and try to re-route issues raised there to our JIRA. I think there have been three pull requests so far, two of them duplicates of JIRA tickets that had been addressed and for the third I created a ticket and managed to close the PR through some magical incantation in the commit message. In short, github is not where the development of the project happens - when it happens as all :-( svn and JIRA at the ASF are the canonical sources. I just had a look, the "trunk" branch in log4net seems to be current and is where log4net will be cut from. I vaguelly recall suggesting to you to merge in the 1.2.x branch to get the latests fixes since your work was based on 1.2.11 or 1.2.12 - trunks looks a bit different but is largely identical to the 1.2.x branch. Much of the restructuring we talked about on this list last fall is finished. We haven't renamed the assembly, yet, and we still sign with both keys - apart from that the documentation hasn't been updated and I wanted to integrate sandcastle instead of ndoc. That being said, I don't think I've found time to work on log4net for two month (this is a recurring theme). >> I'm not quite sure what you are going to suggest in your pull request, >> we'll see. > So is that green light? Green light for what? Nobody will stop you from creating a pull request or attaching a patch to a JIRA issue :-) I for one can't promise any timely response, though. Before you rebase your changes you may want to wait to see what Dominik thinks about splitting out the ASP.NET dependent code, though. For one it would be a waste of your time if it was clear we wouldn't do it - and OTOH I might be able to sneak in some time for log4net in about two weeks, likely not earlier than that. Stefan
Re: Thoughts on 1.3
Hi 1. "to split log4net-13.dll so that the main assembly can be used for the client profile and a separate assembly contains the stuff that requires System.Web - this way we no longer need the -cp builds." Dominik convinced me there was no future for the client profiles anyway, but back then I didn't think about mobile platforms, much less Xamarin. It is up to You. I'm willing to help. I see few trends when people port their apps to mobile (Xamarin.mobile) profiles 1. remove log4net (and other) code 2. switching to other frameworks (like Nlog) 3. writing their own cross platform logging libs 4. using separate code 5. not logging I think lof4net is great utility, structure can easily be prepared for mobile profile. I mean You have seen it. log4net as library was intact. 2. add separate assemblies for async/await (netfx 4.5, mono 3.x), so people are not forced into 4.5. It doesn't look as if we were working on C# 5 code, no worries. OK. This makes a bit less work for me. Also Stefan asked me to merge code into 1.2.x (1.2.13) branch, so I'll do that in next few days and issue pull request as soon as I'm done. I will try to be least intrusive, so will probably end up with: Note current trunk has been restructured quite a lot, a lot of folders have been moved around and I doubt our github mirror would track that as proper moves. So github mirror is not actual state of the project? I would refork it and do all the steps again. This would be few days. Then You could check and correct me. I'm not quite sure what you are going to suggest in your pull request, we'll see. So is that green light? cheers Mel Stefan -- Miljenko Cvjetko dipl.ing. ET Direktor/CEO Projektant rjes(enja/Solution Architect Razvojni programer/Senior developer Voditelj projekta/Project Manager IX juz(na obala 13 Kajzerica Zagreb T: 385 1 777 M: 385 91 557 447 3 F: 385 1 7779556 e: mcvje...@holisticware.net w: http://holisticware.net
Re: Thoughts on 1.3
Hi On 2014.02.04 13:24, w...@poczta.fm wrote: Hi If You work on port of log4net to Xamarin You may find helpful the patch attached to LOG4NET-338 "Port of log4net for MonoDroid" (https://issues.apache.org/jira/browse/LOG4NET-338). I saw Your patch after I was finished. AndroidAppender was almost the same. My port does not change the structure of the library however some parts may still work for You. I was b bit more "radical" and intrusive, so I split the lib into client profile and non-client profile. pozdrawiam Mel Regards Wojciech Dec Od: "Miljenko Cvjetko" Do: log4net-dev@logging.apache.org; Wysłane: 15:47 Poniedziałek 2014-02-03 Temat: Thoughts on 1.3 Hi I have tried to post this one through the nabble on Nov 25th and 26th. My post are still there as "not accepted". Then I got dragged away with projects, then holidays and again projects. Now I have a bit easier, so I’d like to add few thoughts. My name is Miljenko Cvjetko and I'm the one that forked log4net on GitHub, did some structural changes on the solution/project in order to "port" it to Xamarin Mobile profiles (Xamarin.iOS and Xamarin.Android) and contacted Stefan for a permission to submit log4net Xamarin Component to Xamarin Componet Store. Stefan asked me whether I can put some thoughts and more light on the subject in this thread about the Version 1.3. There were several questions both on mailing-lists and forums about availability of the log4net for Mono Mobile profiles (Xamarin Mobile) and I was personally faced with that issue when our team worked on Application that uses mobile port of SharpSNMP, which uses log4net. The quick and dirty workaround was to exclude the dependency (and comment it out). The era of mobile enterprise apps is about to begin and a lot of code will be ported from desktop and server side (ASP.net) to mobile in order to reuse code. Almost all utilities/libraries/tools for .net have disadvantage/handicap that they are written for desktop and/or ASP.net, thus using APIs and/or concepts that are not acceptable or possible on mobile devices. To name some: System.Web assembly (used by log4net) and Configuration utilities which need Xml support. What I actually did is simply split log4net into 2 assemblies, the one with client profile called log4net.client and the other with only ASP.net specific stuff with old name log4net. The code was source-linked, so log4net was for external usage the same as it used to be. All unit tests passed w/o problems. So I would suggest You to do as Stefan suggested: 1. "to split log4net-13.dll so that the main assembly can be used for the client profile and a separate assembly contains the stuff that requires System.Web - this way we no longer need the -cp builds." 2. add separate assemblies for async/await (netfx 4.5, mono 3.x), so people are not forced into 4.5. I have worked with log4net on Xamarin's alpha channel for last 2 months and experienced no problems only stuff I would suggest to add async wrappers (suggestion 2.). Also Stefan asked me to merge code into 1.2.x (1.2.13) branch, so I'll do that in next few days and issue pull request as soon as I'm done. I will try to be least intrusive, so will probably end up with: 1. src folder with ASP.net project (dependencies), so it is the same for regression and backward compatibility 2. src-client (or whatever) with client profile - this might be even PCL - I have to see. 3. src-mobile for iOS and Android assemblies. Xamarin Component stuff will be added later on. I hope I did not bother You too much and thank You best regards Mel -- Miljenko Cvjetko dipl.ing. ET Direktor/CEO Projektant rješenja/Solution Architect Razvojni programer/Senior developer Voditelj projekta/Project Manager IX južna obala 13 Kajzerica Zagreb T: 385 1 777 M: 385 91 557 447 3 F: 385 1 7779556 e: mcvje...@holisticware.net w: http://holisticware.net -- Miljenko Cvjetko dipl.ing. ET Direktor/CEO Projektant rješenja/Solution Architect Razvojni programer/Senior developer Voditelj projekta/Project Manager IX južna obala 13 Kajzerica Zagreb T: 385 1 777 M: 385 91 557 447 3 F: 385 1 7779556 e: mcvje...@holisticware.net w: http://holisticware.net
Re: Thoughts on 1.3
On 2014-02-03, Miljenko Cvjetko wrote: > So I would suggest You to do as Stefan suggested: > 1. "to split log4net-13.dll so that the main assembly can be used for > the client profile and a separate assembly contains the stuff that > requires System.Web - this way we no longer need the -cp builds." Dominik convinced me there was no future for the client profiles anyway, but back then I didn't think about mobile platforms, much less Xamarin. > 2. add separate assemblies for async/await (netfx 4.5, mono 3.x), so > people are not forced into 4.5. It doesn't look as if we were working on C# 5 code, no worries. > Also Stefan asked me to merge code into 1.2.x (1.2.13) branch, so I'll > do that in next few days and issue pull request as soon as I'm done. I > will try to be least intrusive, so will probably end up with: Note current trunk has been restructured quite a lot, a lot of folders have been moved around and I doubt our github mirror would track that as proper moves. I'm not quite sure what you are going to suggest in your pull request, we'll see. Stefan
Re: AW: Thoughts on 1.3
Hi Dominik Yes I know. I contacted Stefan (I think - October aor November) when I finished port. He asked me to put it on the mailing list, so we could discuss it. I don't know Your decision and roadmap or even if this is interesting for You. I could split it, port it to be ready for iOS and Android and then raise pull request. As far as I can remember Stefan said that I used some obsolete constructor for AndroidAppender. Stuff like this - it would be the best if You guys coudl check and correct. I could prepare Xamarin.Component I have submitted it - had some problems during runs in Xamarin Component team, although it passed their Test Cloud Tests without any problems. So my idea was before further steps to contact You and do the changes if YOu agree. thanks regards mel On 2014.02.04 11:58, Dominik Psenner wrote: Stefan posted the outline of this idea already a few months past: http://mail-archives.apache.org/mod_mbox/logging-log4net-dev/201310.mbox/%3C 87hac6nee2@v35516.1blu.de%3E -Ursprüngliche Nachricht- Von: Miljenko Cvjetko [mailto:mcvje...@holisticware.net] Gesendet: Montag, 3. Februar 2014 15:46 An: log4net-dev@logging.apache.org Betreff: Thoughts on 1.3 Hi I have tried to post this one through the nabble on Nov 25th and 26th. My post are still there as "not accepted". Then I got dragged away with projects, then holidays and again projects. Now I have a bit easier, so I'd like to add few thoughts. My name is Miljenko Cvjetko and I'm the one that forked log4net on GitHub, did some structural changes on the solution/project in order to "port" it to Xamarin Mobile profiles (Xamarin.iOS and Xamarin.Android) and contacted Stefan for a permission to submit log4net Xamarin Component to Xamarin Componet Store. Stefan asked me whether I can put some thoughts and more light on the subject in this thread about the Version 1.3. There were several questions both on mailing-lists and forums about availability of the log4net for Mono Mobile profiles (Xamarin Mobile) and I was personally faced with that issue when our team worked on Application that uses mobile port of SharpSNMP, which uses log4net. The quick and dirty workaround was to exclude the dependency (and comment it out). The era of mobile enterprise apps is about to begin and a lot of code will be ported from desktop and server side (ASP.net) to mobile in order to reuse code. Almost all utilities/libraries/tools for .net have disadvantage/handicap that they are written for desktop and/or ASP.net, thus using APIs and/or concepts that are not acceptable or possible on mobile devices. To name some: System.Web assembly (used by log4net) and Configuration utilities which need Xml support. What I actually did is simply split log4net into 2 assemblies, the one with client profile called log4net.client and the other with only ASP.net specific stuff with old name log4net. The code was source-linked, so log4net was for external usage the same as it used to be. All unit tests passed w/o problems. So I would suggest You to do as Stefan suggested: 1. "to split log4net-13.dll so that the main assembly can be used for the client profile and a separate assembly contains the stuff that requires System.Web - this way we no longer need the -cp builds." 2. add separate assemblies for async/await (netfx 4.5, mono 3.x), so people are not forced into 4.5. I have worked with log4net on Xamarin's alpha channel for last 2 months and experienced no problems only stuff I would suggest to add async wrappers (suggestion 2.). Also Stefan asked me to merge code into 1.2.x (1.2.13) branch, so I'll do that in next few days and issue pull request as soon as I'm done. I will try to be least intrusive, so will probably end up with: 1. src folder with ASP.net project (dependencies), so it is the same for regression and backward compatibility 2. src-client (or whatever) with client profile - this might be even PCL - I have to see. 3. src-mobile for iOS and Android assemblies. Xamarin Component stuff will be added later on. I hope I did not bother You too much and thank You best regards Mel -- Miljenko Cvjetko dipl.ing. ET Direktor/CEO Projektant rješenja/Solution Architect Razvojni programer/Senior developer Voditelj projekta/Project Manager IX južna obala 13 Kajzerica Zagreb T: 385 1 777 M: 385 91 557 447 3 F: 385 1 7779556 e: mcvje...@holisticware.net w: http://holisticware.net -- Miljenko Cvjetko dipl.ing. ET Direktor/CEO Projektant rješenja/Solution Architect Razvojni programer/Senior developer Voditelj projekta/Project Manager IX južna obala 13 Kajzerica Zagreb T: 385 1 777 M: 385 91 557 447 3 F: 385 1 7779556 e: mcvje...@holisticware.net w: http://holisticware.net
Re: Thoughts on 1.3
Hi If You work on port of log4net to Xamarin You may find helpful the patch attached to LOG4NET-338 "Port of log4net for MonoDroid" (https://issues.apache.org/jira/browse/LOG4NET-338). My port does not change the structure of the library however some parts may still work for You. Regards Wojciech Dec Od: "Miljenko Cvjetko" Do: log4net-dev@logging.apache.org; Wysłane: 15:47 Poniedziałek 2014-02-03 Temat: Thoughts on 1.3 > Hi > > I have tried to post this one through the nabble on Nov 25th and 26th. > My post are still there as "not accepted". Then I got dragged away with > projects, then holidays and again projects. Now I have a bit easier, so > I’d like to add few thoughts. > > My name is Miljenko Cvjetko and I'm the one that forked log4net on > GitHub, did some structural changes on the solution/project in order to > "port" it to Xamarin Mobile profiles (Xamarin.iOS and Xamarin.Android) > and contacted Stefan for a permission to submit log4net Xamarin > Component to Xamarin Componet Store. > > Stefan asked me whether I can put some thoughts and more light on the > subject in this thread about the Version 1.3. > > There were several questions both on mailing-lists and forums about > availability of the log4net for Mono Mobile profiles (Xamarin Mobile) > and I was personally faced with that issue when our team worked on > Application that uses mobile port of SharpSNMP, which uses log4net. The > quick and dirty workaround was to exclude the dependency (and comment it > out). > > The era of mobile enterprise apps is about to begin and a lot of code > will be ported from desktop and server side (ASP.net) to mobile in order > to reuse code. Almost all utilities/libraries/tools for .net have > disadvantage/handicap that they are written for desktop and/or ASP.net, > thus using APIs and/or concepts that are not acceptable or possible on > mobile devices. To name some: System.Web assembly (used by log4net) and > Configuration utilities which need Xml support. > > What I actually did is simply split log4net into 2 assemblies, the one > with client profile called log4net.client and the other with only > ASP.net specific stuff with old name log4net. The code was > source-linked, so log4net was for external usage the same as it used to be. > > All unit tests passed w/o problems. > > So I would suggest You to do as Stefan suggested: > > 1. "to split log4net-13.dll so that the main assembly can be used for > the client profile and a separate assembly contains the stuff that > requires System.Web - this way we no longer need the -cp builds." > > 2. add separate assemblies for async/await (netfx 4.5, mono 3.x), so > people are not forced into 4.5. > > I have worked with log4net on Xamarin's alpha channel for last 2 months > and experienced no problems only stuff I would suggest to add async > wrappers (suggestion 2.). > > Also Stefan asked me to merge code into 1.2.x (1.2.13) branch, so I'll > do that in next few days and issue pull request as soon as I'm done. I > will try to be least intrusive, so will probably end up with: > > 1. src folder with ASP.net project (dependencies), so it is the same for > regression and backward compatibility > 2. src-client (or whatever) with client profile - this might be even PCL > - I have to see. > 3. src-mobile for iOS and Android assemblies. > > Xamarin Component stuff will be added later on. > > I hope I did not bother You too much and thank You > > best regards > > Mel > > -- > Miljenko Cvjetko dipl.ing. ET > Direktor/CEO > Projektant rješenja/Solution Architect > Razvojni programer/Senior developer > Voditelj projekta/Project Manager > > IX južna obala 13 > Kajzerica Zagreb > T: 385 1 777 > M: 385 91 557 447 3 > F: 385 1 7779556 > e: mcvje...@holisticware.net > w: http://holisticware.net > >
AW: Thoughts on 1.3
Stefan posted the outline of this idea already a few months past: http://mail-archives.apache.org/mod_mbox/logging-log4net-dev/201310.mbox/%3C 87hac6nee2@v35516.1blu.de%3E >-Ursprüngliche Nachricht- >Von: Miljenko Cvjetko [mailto:mcvje...@holisticware.net] >Gesendet: Montag, 3. Februar 2014 15:46 >An: log4net-dev@logging.apache.org >Betreff: Thoughts on 1.3 > >Hi > >I have tried to post this one through the nabble on Nov 25th and 26th. >My post are still there as "not accepted". Then I got dragged away with >projects, then holidays and again projects. Now I have a bit easier, so >I'd like to add few thoughts. > >My name is Miljenko Cvjetko and I'm the one that forked log4net on >GitHub, did some structural changes on the solution/project in order to >"port" it to Xamarin Mobile profiles (Xamarin.iOS and Xamarin.Android) >and contacted Stefan for a permission to submit log4net Xamarin >Component to Xamarin Componet Store. > >Stefan asked me whether I can put some thoughts and more light on the >subject in this thread about the Version 1.3. > >There were several questions both on mailing-lists and forums about >availability of the log4net for Mono Mobile profiles (Xamarin Mobile) >and I was personally faced with that issue when our team worked on >Application that uses mobile port of SharpSNMP, which uses log4net. The >quick and dirty workaround was to exclude the dependency (and comment it >out). > >The era of mobile enterprise apps is about to begin and a lot of code >will be ported from desktop and server side (ASP.net) to mobile in order >to reuse code. Almost all utilities/libraries/tools for .net have >disadvantage/handicap that they are written for desktop and/or ASP.net, >thus using APIs and/or concepts that are not acceptable or possible on >mobile devices. To name some: System.Web assembly (used by log4net) and >Configuration utilities which need Xml support. > >What I actually did is simply split log4net into 2 assemblies, the one >with client profile called log4net.client and the other with only >ASP.net specific stuff with old name log4net. The code was >source-linked, so log4net was for external usage the same as it used to be. > >All unit tests passed w/o problems. > >So I would suggest You to do as Stefan suggested: > >1. "to split log4net-13.dll so that the main assembly can be used for >the client profile and a separate assembly contains the stuff that >requires System.Web - this way we no longer need the -cp builds." > >2. add separate assemblies for async/await (netfx 4.5, mono 3.x), so >people are not forced into 4.5. > >I have worked with log4net on Xamarin's alpha channel for last 2 months >and experienced no problems only stuff I would suggest to add async >wrappers (suggestion 2.). > >Also Stefan asked me to merge code into 1.2.x (1.2.13) branch, so I'll >do that in next few days and issue pull request as soon as I'm done. I >will try to be least intrusive, so will probably end up with: > >1. src folder with ASP.net project (dependencies), so it is the same for >regression and backward compatibility >2. src-client (or whatever) with client profile - this might be even PCL >- I have to see. >3. src-mobile for iOS and Android assemblies. > >Xamarin Component stuff will be added later on. > >I hope I did not bother You too much and thank You > >best regards > >Mel > >-- >Miljenko Cvjetko dipl.ing. ET > Direktor/CEO > Projektant rješenja/Solution Architect > Razvojni programer/Senior developer > Voditelj projekta/Project Manager > >IX južna obala 13 >Kajzerica Zagreb >T: 385 1 777 >M: 385 91 557 447 3 >F: 385 1 7779556 >e: mcvje...@holisticware.net >w: http://holisticware.net
Thoughts on 1.3
Hi I have tried to post this one through the nabble on Nov 25th and 26th. My post are still there as "not accepted". Then I got dragged away with projects, then holidays and again projects. Now I have a bit easier, so I’d like to add few thoughts. My name is Miljenko Cvjetko and I'm the one that forked log4net on GitHub, did some structural changes on the solution/project in order to "port" it to Xamarin Mobile profiles (Xamarin.iOS and Xamarin.Android) and contacted Stefan for a permission to submit log4net Xamarin Component to Xamarin Componet Store. Stefan asked me whether I can put some thoughts and more light on the subject in this thread about the Version 1.3. There were several questions both on mailing-lists and forums about availability of the log4net for Mono Mobile profiles (Xamarin Mobile) and I was personally faced with that issue when our team worked on Application that uses mobile port of SharpSNMP, which uses log4net. The quick and dirty workaround was to exclude the dependency (and comment it out). The era of mobile enterprise apps is about to begin and a lot of code will be ported from desktop and server side (ASP.net) to mobile in order to reuse code. Almost all utilities/libraries/tools for .net have disadvantage/handicap that they are written for desktop and/or ASP.net, thus using APIs and/or concepts that are not acceptable or possible on mobile devices. To name some: System.Web assembly (used by log4net) and Configuration utilities which need Xml support. What I actually did is simply split log4net into 2 assemblies, the one with client profile called log4net.client and the other with only ASP.net specific stuff with old name log4net. The code was source-linked, so log4net was for external usage the same as it used to be. All unit tests passed w/o problems. So I would suggest You to do as Stefan suggested: 1. "to split log4net-13.dll so that the main assembly can be used for the client profile and a separate assembly contains the stuff that requires System.Web - this way we no longer need the -cp builds." 2. add separate assemblies for async/await (netfx 4.5, mono 3.x), so people are not forced into 4.5. I have worked with log4net on Xamarin's alpha channel for last 2 months and experienced no problems only stuff I would suggest to add async wrappers (suggestion 2.). Also Stefan asked me to merge code into 1.2.x (1.2.13) branch, so I'll do that in next few days and issue pull request as soon as I'm done. I will try to be least intrusive, so will probably end up with: 1. src folder with ASP.net project (dependencies), so it is the same for regression and backward compatibility 2. src-client (or whatever) with client profile - this might be even PCL - I have to see. 3. src-mobile for iOS and Android assemblies. Xamarin Component stuff will be added later on. I hope I did not bother You too much and thank You best regards Mel -- Miljenko Cvjetko dipl.ing. ET Direktor/CEO Projektant rješenja/Solution Architect Razvojni programer/Senior developer Voditelj projekta/Project Manager IX južna obala 13 Kajzerica Zagreb T: 385 1 777 M: 385 91 557 447 3 F: 385 1 7779556 e: mcvje...@holisticware.net w: http://holisticware.net
Re: Thoughts on 1.3
Sorry for formatting. Pasted it directly from google docs into thunderbird and here it looked OK. sorry one more time mel On 2014.02.03 15:32, Miljenko Cvjetko wrote: * Hi I have tried to post this one through the nabble on Nov 25th and 26th. The I got dragged away with projects, then holidays and again projects. Now I have a bit easier, so I'd like to add few thoughts. My name is Miljenko Cvjetko and I'm the one that forked log4net on GitHub, did some structural changes on the solution/project in order to "port" it to Xamarin Mobile profiles (Xamarin.iOS and Xamarin.Android) and contacted Stefan for a permission to submit log4net Xamarin Component to Xamarin Componet Store. Stefan asked me whether I can put some thoughts and more light on the subject in this thread about the Version 1.3. There were several questions both on mailing-lists and forums about availability of the log4net for Mono Mobile profiles (Xamarin Mobile) and I was personally faced with that issue when our team worked on Application that uses mobile port of SharpSNMP, which uses log4net. The quick and dirty workaround was to exclude the dependency (and comment it out). The era of mobile enterprise apps is about to begin and a lot of code will be ported from desktop and server side (ASP.net) to mobile in order to reuse code. Almost all utilities/libraries/tools for .net have disadvantage/handicap that they are written for desktop and/or ASP.net, thus using APIs and/or concepts that are not acceptable or possible on mobile devices. To name some: System.Web assembly (used by log4net) and Configuration utilities which need Xml support. What I actually did is simply split log4net into 2 assemblies, the one with client profile called log4net.client and the other with only ASP.net specific stuff with old name log4net. The code was source-linked, so log4net was for external usage the same as it used to be. All unit tests passed w/o problems. So I would suggest You to do as Stefan suggested: 1. "to split log4net-13.dll so that the main assembly can be used for the client profile and a separate assembly contains the stuff that requires System.Web - this way we no longer need the -cp builds." 2. add separate assemblies for async/await (netfx 4.5, mono 3.x), so people are not forced into 4.5. I have worked with log4net on Xamarin's alpha channel for last 2 months and experienced no problems only stuff I would suggest to add async wrappers (suggestion 2.). Also Stefan asked me to merge code into 1.2.x (1.2.13) branch, so I'll do that in next few days and issue pull request as soon as I'm done. I will try to be least intrusive, so will probably end up with: 1. src folder with ASP.net project (dependencies), so it is the same for regression and backward compatibility 2. src-client (or whatever) with client profile - this might be even PCL - I have to see. 3. src-mobile for iOS and Android assemblies. Xamarin Component stuff will be added later on. I hope I did not bother You too much and thank You best regards Mel * -- Miljenko Cvjetko dipl.ing. ET Direktor/CEO Projektant rjes(enja/Solution Architect Razvojni programer/Senior developer Voditelj projekta/Project Manager IX juz(na obala 13 Kajzerica Zagreb T: 385 1 777 M: 385 91 557 447 3 F: 385 1 7779556 e:mcvje...@holisticware.net w:http://holisticware.net -- Miljenko Cvjetko dipl.ing. ET Direktor/CEO Projektant rjes(enja/Solution Architect Razvojni programer/Senior developer Voditelj projekta/Project Manager IX juz(na obala 13 Kajzerica Zagreb T: 385 1 777 M: 385 91 557 447 3 F: 385 1 7779556 e: mcvje...@holisticware.net w: http://holisticware.net
AW: Thoughts on 1.3
http://mail-archives.apache.org/mod_mbox/logging-log4net-dev/201310.mbox/%3C CADVsjzOOzbBHOcKXRhqO-buGn5uEvurLy0WfykxqRMmtyPwvFw%40mail.gmail.com%3E Von: Ramon Smits [mailto:ramon.sm...@gmail.com] Gesendet: Montag, 28. Oktober 2013 12:04 An: Log4NET Dev Betreff: Re: Thoughts on 1.3 Why not just apply semver and make it v2? -- Ramon On Mon, Oct 28, 2013 at 8:36 AM, Dominik Psenner mailto:dpsen...@gmail.com> > wrote: >On 2013-10-25, Dominik Psenner wrote: > >>> * the next release will be 1.3.0 and require .NET 2.0 or better > >>> I.e. we remove support for .NET 1.0 and 1.1, Compact Framework 1.0, >>> Mono < 2.0, SSCLI and CLI 1.0 frameworks > >> That's even worth a +2! ;-) > >>> * the main assembly will get a new name like log4net-13.dll, only be >>> signed by the new key > >>> * we provide two assemblies named log4net.dll signed with the old and >>> new key respecitvely that contain type forwards to the new assembly >>> only > >> I'm afraid that I can't quite grasp all the stuff we could break. We should >> definitely work out every possible usecase we may break. We have messed >> enough and should try to not raise the tempers even more. > >Understood, I'll take that to the user list for a bigger audience - >maybe people will see problems that we are overlooking. Worth a try. >>> stuff we haven't talked about, yet: > >>> * I'd like to split log4net-13.dll so that the main assembly can be used >>> for the client profile and a separate assembly contains the stuff that >>> requires System.Web - this way we no longer need the -cp builds. > >> The client profile was dropped with .NET 4.5 and previous versions are >> automatically upgraded to include the missing DLLs once somebody runs an >> update. Thus I'm not sure if we should really split the library and double >> the required efforts. > >I see. I wasn't aware the client profile was dropped again - spending >most if not all of my working hours in Java land has made me lose track, >or so it seems. In that case splitting the assembly doesn't make to >much sense. > >And the client profile builds can be removed when log4net drops support >for .NET 4.0 ten years from now ;-) True. I wanted to quote where I have this information from: http://msdn.microsoft.com/en-us/library/cc656912.aspx
Re: Thoughts on 1.3
Why not just apply semver and make it v2? -- Ramon On Mon, Oct 28, 2013 at 8:36 AM, Dominik Psenner wrote: > >On 2013-10-25, Dominik Psenner wrote: > > > >>> * the next release will be 1.3.0 and require .NET 2.0 or better > > > >>> I.e. we remove support for .NET 1.0 and 1.1, Compact Framework 1.0, > >>> Mono < 2.0, SSCLI and CLI 1.0 frameworks > > > >> That's even worth a +2! ;-) > > > >>> * the main assembly will get a new name like log4net-13.dll, only be > >>> signed by the new key > > > >>> * we provide two assemblies named log4net.dll signed with the old and > >>> new key respecitvely that contain type forwards to the new assembly > >>> only > > > >> I'm afraid that I can't quite grasp all the stuff we could break. We > should > >> definitely work out every possible usecase we may break. We have messed > >> enough and should try to not raise the tempers even more. > > > >Understood, I'll take that to the user list for a bigger audience - > >maybe people will see problems that we are overlooking. > > Worth a try. > > >>> stuff we haven't talked about, yet: > > > >>> * I'd like to split log4net-13.dll so that the main assembly can be > used > >>> for the client profile and a separate assembly contains the stuff that > >>> requires System.Web - this way we no longer need the -cp builds. > > > >> The client profile was dropped with .NET 4.5 and previous versions are > >> automatically upgraded to include the missing DLLs once somebody runs an > >> update. Thus I'm not sure if we should really split the library and > double > >> the required efforts. > > > >I see. I wasn't aware the client profile was dropped again - spending > >most if not all of my working hours in Java land has made me lose track, > >or so it seems. In that case splitting the assembly doesn't make to > >much sense. > > > >And the client profile builds can be removed when log4net drops support > >for .NET 4.0 ten years from now ;-) > > True. I wanted to quote where I have this information from: > > http://msdn.microsoft.com/en-us/library/cc656912.aspx > >
AW: Thoughts on 1.3
>On 2013-10-25, Dominik Psenner wrote: > >>> * the next release will be 1.3.0 and require .NET 2.0 or better > >>> I.e. we remove support for .NET 1.0 and 1.1, Compact Framework 1.0, >>> Mono < 2.0, SSCLI and CLI 1.0 frameworks > >> That's even worth a +2! ;-) > >>> * the main assembly will get a new name like log4net-13.dll, only be >>> signed by the new key > >>> * we provide two assemblies named log4net.dll signed with the old and >>> new key respecitvely that contain type forwards to the new assembly >>> only > >> I'm afraid that I can't quite grasp all the stuff we could break. We should >> definitely work out every possible usecase we may break. We have messed >> enough and should try to not raise the tempers even more. > >Understood, I'll take that to the user list for a bigger audience - >maybe people will see problems that we are overlooking. Worth a try. >>> stuff we haven't talked about, yet: > >>> * I'd like to split log4net-13.dll so that the main assembly can be used >>> for the client profile and a separate assembly contains the stuff that >>> requires System.Web - this way we no longer need the -cp builds. > >> The client profile was dropped with .NET 4.5 and previous versions are >> automatically upgraded to include the missing DLLs once somebody runs an >> update. Thus I'm not sure if we should really split the library and double >> the required efforts. > >I see. I wasn't aware the client profile was dropped again - spending >most if not all of my working hours in Java land has made me lose track, >or so it seems. In that case splitting the assembly doesn't make to >much sense. > >And the client profile builds can be removed when log4net drops support >for .NET 4.0 ten years from now ;-) True. I wanted to quote where I have this information from: http://msdn.microsoft.com/en-us/library/cc656912.aspx
Re: Thoughts on 1.3
On 2013-10-25, Dominik Psenner wrote: >> * the next release will be 1.3.0 and require .NET 2.0 or better >> I.e. we remove support for .NET 1.0 and 1.1, Compact Framework 1.0, >> Mono < 2.0, SSCLI and CLI 1.0 frameworks > That's even worth a +2! ;-) >> * the main assembly will get a new name like log4net-13.dll, only be >> signed by the new key >> * we provide two assemblies named log4net.dll signed with the old and >> new key respecitvely that contain type forwards to the new assembly >> only > I'm afraid that I can't quite grasp all the stuff we could break. We should > definitely work out every possible usecase we may break. We have messed > enough and should try to not raise the tempers even more. Understood, I'll take that to the user list for a bigger audience - maybe people will see problems that we are overlooking. >> stuff we haven't talked about, yet: >> * I'd like to split log4net-13.dll so that the main assembly can be used >> for the client profile and a separate assembly contains the stuff that >> requires System.Web - this way we no longer need the -cp builds. > The client profile was dropped with .NET 4.5 and previous versions are > automatically upgraded to include the missing DLLs once somebody runs an > update. Thus I'm not sure if we should really split the library and double > the required efforts. I see. I wasn't aware the client profile was dropped again - spending most if not all of my working hours in Java land has made me lose track, or so it seems. In that case splitting the assembly doesn't make to much sense. And the client profile builds can be removed when log4net drops support for .NET 4.0 ten years from now ;-) Thanks Stefan
AW: Thoughts on 1.3
>* the next release will be 1.3.0 and require .NET 2.0 or better > > I.e. we remove support for .NET 1.0 and 1.1, Compact Framework 1.0, > Mono < 2.0, SSCLI and CLI 1.0 frameworks That's even worth a +2! ;-) >* the main assembly will get a new name like log4net-13.dll, only be > signed by the new key > >* we provide two assemblies named log4net.dll signed with the old and > new key respecitvely that contain type forwards to the new assembly > only I'm afraid that I can't quite grasp all the stuff we could break. We should definitely work out every possible usecase we may break. We have messed enough and should try to not raise the tempers even more. > >stuff we haven't talked about, yet: > >* I'd like to split log4net-13.dll so that the main assembly can be used > for the client profile and a separate assembly contains the stuff that > requires System.Web - this way we no longer need the -cp builds. The client profile was dropped with .NET 4.5 and previous versions are automatically upgraded to include the missing DLLs once somebody runs an update. Thus I'm not sure if we should really split the library and double the required efforts. It's documented which features are not available when using log4net with the Client profile and maybe we could improve log4net's internal logging to reflect broken things caused by a missing System.Web.dll. >* add support for Mono 4.0 > > Actually I currently can only build Mono 2.0 and 4.0 and 2.0 will be > gone once I replace my really old home machine. I guess I need to > investigate running separate Mono installations in parallel. *cough* automated builds *cough* >* .NET 4.5? Is there anything special about 4.5 or does the 4.0 version > just work? Nothing special as far as I know, but as noted above they finally have dropped that bloody client profile. >* give the user list a heads up so they know about our plans and can > tell us to stop if necessary. Of course. Involve them as much as possible.
Thoughts on 1.3
Hi all, this is just a random list, I'd like to make sure whether we are on the same page before making changes or just give the user list a heads up. My understanding of the discussion which basically happened in JIRA so far: * the next release will be 1.3.0 and require .NET 2.0 or better I.e. we remove support for .NET 1.0 and 1.1, Compact Framework 1.0, Mono < 2.0, SSCLI and CLI 1.0 frameworks * the main assembly will get a new name like log4net-13.dll, only be signed by the new key * we provide two assemblies named log4net.dll signed with the old and new key respecitvely that contain type forwards to the new assembly only stuff we haven't talked about, yet: * I'd like to split log4net-13.dll so that the main assembly can be used for the client profile and a separate assembly contains the stuff that requires System.Web - this way we no longer need the -cp builds. * add support for Mono 4.0 Actually I currently can only build Mono 2.0 and 4.0 and 2.0 will be gone once I replace my really old home machine. I guess I need to investigate running separate Mono installations in parallel. * .NET 4.5? Is there anything special about 4.5 or does the 4.0 version just work? * give the user list a heads up so they know about our plans and can tell us to stop if necessary. Stefan
