AW: Thoughts on 1.3

[Dominik Psenner]

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

[Dominik Psenner]

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:
>>>
>>> 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 Cvjetk

Re: AW: Thoughts on 1.3

[Miljenko Cvjetko]

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

AW: Thoughts on 1.3

[Dominik Psenner]

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

AW: Thoughts on 1.3

[Dominik Psenner]

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

 

AW: Thoughts on 1.3

[Dominik Psenner]

>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

[Dominik Psenner]

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