from:"Dangling Pointer"

Re: String Equality Comparison, Broken Tests and .NET-1.x

2016-08-25 Thread Dangling Pointer

Dominik, looks good. I just quickly typed that code in email compose box. Your 
changes are good enough to get incorporated in code base and to conclude this 
issue IMO.

Agree that the more backward compatible the better. I just raised the point 
that if less than 1% of log4net consumers are on net2.0 and lower, then they 
most probably are not updating their code or dependency packages to the latest 
versions either. So basically it's just like you said that the newer version 
may just focus on mainstream audience; net35 and higher.

> You would not throw away a good 25 year old rum either, would you? :-)

I wouldn't dare. :)

But by analogy if it is C lib, I would just comply with C99 and C11 ISO 
standard and would care less about C89, POSIX'ism etc. []

From: Dominik Psenner <dpsen...@gmail.com>
Sent: Thursday, August 25, 2016 7:52:37 PM
To: Log4NET Dev
Subject: Re: String Equality Comparison, Broken Tests and .NET-1.x

At first glance this will not compile:

public static bool NeutralizeString(string input)
{
return string.IsNullOrEmpty(input) &&
input.ToUpper(CultureInfo.InvariantCulture);
}

Further, the name of the method does not fit yet the purpose of the code. Last 
but not least, I would advise to make it internal.

internal static string GetStringOrEmptyIfNull(string input)
  if (string.IsNullOrEmpty(input))
return input.ToUpper(CultureInfo.InvariantCulture;
  else
return string.Empty;

> PS - awesome that log4net has thus far maintain the compatibility with 
> .NET1.1! but are there still consumers of .NET1.1?

There has been a discussion about this some time ago. Please check the mailing 
list backlog. The outcome was that we are stopping to maintain everything that 
is older than .NET 3.5 (exclusive). If someone wants to have it, he must A) 
compile it from source and B) fix the source if it does no longer compile. If 
the effort is cheap, we will however try to keep it compatible because of 
reasons. Maybe we are just old guys that like good old stuff. You would not 
throw away a good 25 year old rum either, would you? :-)

2016-08-25 18:59 GMT+02:00 Dangling Pointer 
<danglingpoin...@outlook.com<mailto:danglingpoin...@outlook.com>>:

> Unfortunately, this doesn't work if `a` is allowed to be null.

I made this change in https://github.com/apache/log4net/pull/30. I think we can 
use:

trimmedTargetName?.ToUpperInvariant()

in C#6 syntax or the older syntax:

string.IsNullOrEmpty(trimmedTargetName) && trimmedTargetName.ToUpperInvariant()

to fix this problem.

For .NET 1.1 compatibility, we can just use,

string.IsNullOrEmpty(trimmedTargetName) && 
trimmedTargetName.ToUpper(CultureInfo.InvariantCulture);
everywhere without branching out with preprocessor directives.

Or maybe a helper method:

public static bool NeutralizeString(string input)
{
return string.IsNullOrEmpty(input) &&
input.ToUpper(CultureInfo.InvariantCulture);
}

Then use NeutralizeString(strA) == NeutralizeString(strB) without specializing 
for various versions of framework.

PS - awesome that log4net has thus far maintain the compatibility with .NET1.1! 
but are there still consumers of .NET1.1? Why would they care to update the 
NuGet package, the next version of log4net, when they don't have time to 
upgrade their project to newer version of the framework.. just a thought.. :p

From: jonas.ba...@rohde-schwarz.com<mailto:jonas.ba...@rohde-schwarz.com> 
<jonas.ba...@rohde-schwarz.com<mailto:jonas.ba...@rohde-schwarz.com>>
Sent: Tuesday, August 23, 2016 1:50:29 PM
To: Log4NET Dev
Subject: Re: String Equality Comparison, Broken Tests and .NET-1.x

Stefan Bodewig <bode...@apache.org<mailto:bode...@apache.org>> wrote on 
23.08.2016 06:14:32:

> Von: Stefan Bodewig <bode...@apache.org<mailto:bode...@apache.org>>
> An: "Log4Net Developers List" 
> <log4net-dev@logging.apache.org<mailto:log4net-dev@logging.apache.org>>
> Datum: 23.08.2016 06:14
> Betreff: Re: String Equality Comparison, Broken Tests and .NET-1.x
>
> On 2016-08-22, 
> <jonas.ba...@rohde-schwarz.com<mailto:jonas.ba...@rohde-schwarz.com>> wrote:
>
> > A recent commit [1] changed, among other things, some string equality
> > comparisons from `SomeComparer.Compare(a, "B", IgnoreCase) == 0` to
> > `a.ToUpperInvariant() == "B"`, see also [2].
> >
> > Unfortunately, this doesn't work if `a` is allowed to be null. Currently a
> > lot of log4net.Tests are broken because of such a null reference exception
> > in `NewLinePatternConverter.ActivateOptions` (apparently "%newline" is
> > quite common in pattern layouts ;-).
>
> Oh, I'm sorry. I must admit I glanced over the PR and applied it without
> runni

Re: String Equality Comparison, Broken Tests and .NET-1.x

2016-08-25 Thread Dangling Pointer

> Unfortunately, this doesn't work if `a` is allowed to be null.

I made this change in https://github.com/apache/log4net/pull/30. I think we can 
use:

trimmedTargetName?.ToUpperInvariant()

in C#6 syntax or the older syntax:

string.IsNullOrEmpty(trimmedTargetName) && trimmedTargetName.ToUpperInvariant()

to fix this problem.

For .NET 1.1 compatibility, we can just use,

string.IsNullOrEmpty(trimmedTargetName) && 
trimmedTargetName.ToUpper(CultureInfo.InvariantCulture);
everywhere without branching out with preprocessor directives.

Or maybe a helper method:

public static bool NeutralizeString(string input)
{
return string.IsNullOrEmpty(input) &&
input.ToUpper(CultureInfo.InvariantCulture);
}

Then use NeutralizeString(strA) == NeutralizeString(strB) without specializing 
for various versions of framework.

PS - awesome that log4net has thus far maintain the compatibility with .NET1.1! 
but are there still consumers of .NET1.1? Why would they care to update the 
NuGet package, the next version of log4net, when they don't have time to 
upgrade their project to newer version of the framework.. just a thought.. :p

From: jonas.ba...@rohde-schwarz.com 
Sent: Tuesday, August 23, 2016 1:50:29 PM
To: Log4NET Dev
Subject: Re: String Equality Comparison, Broken Tests and .NET-1.x

Stefan Bodewig  wrote on 23.08.2016 06:14:32:

> Von: Stefan Bodewig 
> An: "Log4Net Developers List" 
> Datum: 23.08.2016 06:14
> Betreff: Re: String Equality Comparison, Broken Tests and .NET-1.x
>
> On 2016-08-22,  wrote:
>
> > A recent commit [1] changed, among other things, some string equality
> > comparisons from `SomeComparer.Compare(a, "B", IgnoreCase) == 0` to
> > `a.ToUpperInvariant() == "B"`, see also [2].
> >
> > Unfortunately, this doesn't work if `a` is allowed to be null. Currently a
> > lot of log4net.Tests are broken because of such a null reference exception
> > in `NewLinePatternConverter.ActivateOptions` (apparently "%newline" is
> > quite common in pattern layouts ;-).
>
> Oh, I'm sorry. I must admit I glanced over the PR and applied it without
> running the tests. My fault.
>
> > For new code I tend to opt for `String.Equals(Option, "DOS",
> > StringComparison.OrdinalIgnoreCase)` for a fast, case-insensitive
> > comparison with fixed ASCII-only patterns, but static
> > `String.Equals(String, String, StringComparison)` is not awailable on
> > .NET-1.x [3].
>
> This is what the original code before PR #16 looked like, but it doesn't
> seem to be available for .NET Core, see the discussion around
> https://github.com/apache/log4net/pull/16/
> files#diff-51624ab11a9b3d95cc770de1a4e1bdbc

Note quite, it used `string.compare(string, string, bool, CultireInfo) == 0` 
which is available on .NET-1.x, while `String.Equals(string, string 
StringComparison)` and `ToUpperInvariant` are not.

> > Should we create some helper in SystemInfo that provides null-aware,
> > ordinal, casing-agnostic string equality comparison, with some #if's
> > .NET-1.x?
>
> +1

Here you go. The attached patch introduces a 
`SystemInfo.EqualsIgnoringCase(string, string)`, some unit tests, and fixes 
`NewLinePatternConverter.ActivateOptions` so that the test suite passes again.

Please note that I was only able to test with .NET-4.5.2. I have no .NET-1x 
around, nor .NET Core (maybe we can even drop this #elif). I used the code for 
these platforms from previous revisions of NewLinePatternConverter.cs. In 
addition, I'm not sure if I got all the defines for the #if right. Is there 
some doc for that?

regards,
Jonas

Re: Questions About the .NET Core Build

2016-08-21 Thread Dangling Pointer

We are using signed assemblies in autofac-moq like this: 
https://github.com/autofac/Autofac.Extras.Moq/blob/d38df6d/src/Autofac.Extras.Moq/project.json#L6.
 It is just a matter of setting the path to snk file in project.json. You can 
find full set of options in the project.json published schema here: 
https://github.com/SchemaStore/schemastore/blob/b24ea2f/src/schemas/json/project.json#L239.


Regarding the target framework moniker, TFM question; net4xx, xamrinxx, 
monoAndroidxx, monoTouchxx they all map to Mono PCL on Unix. Which means you 
need mono portable class libraries (or full mono) installed on the system 
running the code. However, when your app targets netstandard1x or netcore1.x, 
then you have no dependency on mono and it just works on macOS and Linux. See 
our TravisCI script 
https://github.com/nunit/dotnet-test-nunit/blob/master/.travis.yml which uses 
language "generic" to get a base Linux / OSX box, installs some native packages 
(libicu etc.) and runs the project from there. Similar work was ported to this 
project: https://github.com/autofac/Autofac.Extras.Moq/blob/develop/.travis.yml 
(don't mind the invasive JS code, that is for a bug in CLI and I have ranted in 
dotnet/cli issue tracker a lot about it so expect it to get fixed in vNext of 
CLI). Other than that pretty straight forward and zero dependency on Mono for 
netstandard.


So if you need to consume full framework on Unix, use net4x and have Mono 
installed on the system. If you are authoring a new project, then (if possible) 
probably a good idea to mark CoreFX subset as a baseline to write a 
pure-portable code and achieve maximum portability. They are closing the gap 
with all hands on desk in next version of netstandard, but some API methods are 
permanently retired as those were bad idea to put into the framework in first 
place (like GetCallingAssembly, which log4net any many other logging libs 
heavily rely on and the reasoning to have it retired in netstandard can be 
found here: https://github.com/dotnet/corefx/issues/1784). Other than that, 
every coming day .NET Core is getting better, CoreCLR getting highly optimized 
and more cross platform stuff is being incorporated.


If you need help in porting your open source lib etc. ping me on GitHub 
(@jasonwilliams200ok). Build systems is kinda my thing. So happy to chime into 
any OSS project.. :)


BR


From: Dominik Psenner 
Sent: Sunday, August 21, 2016 7:51:05 PM
To: Log4NET Dev
Subject: Re: Questions About the .NET Core Build



2016-08-21 18:28 GMT+02:00 Stefan Bodewig 
>:
Hi

I've got a bunch of questions about the .NET Core build and before I
spend more time searching for the anwers I though I may as well ask for
help.

Version
===

The current version is set as 3.0.0 - why? log4net's next assembly
version is 1.2.16. I know the nuget package uses 2.x - probably because
it changed the major version when it switched to the new key - but
adding another platform shouldn't require a new major version IMHO.

I was puzzled by 3.0.0 too. We could however use the opportunity to
line up all the different version numbers between the codebase, nuget
and .net core extension.


4.x Builds
==

On my Linux box it builds assemblies for net40 and net45 as well. Are
these assemblies expected to be the same as the assemblies we build
using NAnt? If so, I may be able to use the net45 version built by the
dotnet too as NAnt really doesn't seem to want to use 4.5 for me.

I can build the net40 and net45 assemblies on my windows 7 machine. We
could then compare binary compatibility and a few other things to double
check if these binaries are the same. md5 won't do because of the meta data
changes that are written into the binary on every build.


Signing
===

I'd like to see strong named assemblies using "the new key" is this
supported?

.NET core supports also strong named assemblies. At least there are a few
strong named assemblies out there and a few that are not strong named too.
A quick hack in the search engine brought up a few results.
--
Dominik Psenner

Re: Proposal - log4net extensions pacakge for ASP.NET Core

2016-08-20 Thread Dangling Pointer

> That is true. Ownership transfer is on the to do list.

Ah, good news is there is a workaround that we can build the extension project 
as part of the same solution as log4net project. Once we get package publishing 
sorted out, we can use it. I have issued the pull request:

https://github.com/apache/log4net/pull/32

(with instructions how to test it on Unix and Windows)

> Are there other logging framework that have been candidated or are already 
> part of .net core?

Yup, as noted in my first post in this thread, all the major Logging providers 
are supporting the aspnet interface. Here is the list: 
https://github.com/aspnet/Logging/blob/dev/README.md#providers. The interface 
itself has its limitations, but there is still a potential to provide this 
extension so to provide the opt-in experience for aspnet core apps.

From: Dominik Psenner <dpsen...@gmail.com>
Sent: Saturday, August 20, 2016 11:00:57 PM
To: Log4NET Dev
Cc: Stefan Bodewig
Subject: Re: Proposal - log4net extensions pacakge for ASP.NET Core

That is true. Ownership transfer is on the to do list.

The actual problem is that log4net has, by ASF standards, not the manpower to 
survive. There should be 3 active developers on the project, otherwise a 
project should be retired and put to attic. Attic can be seen as a dormant 
state of the project.

Are there other logging framework that have been candidated or are already part 
of .net core?

On 21 Aug 2016 12:49 a.m., "Dangling Pointer" 
<danglingpoin...@outlook.com<mailto:danglingpoin...@outlook.com>> wrote:

I am unaware about ownership discussion. Is it so that NuGet package is not 
owned by the repo maintainers?

From: Dominik Psenner <dpsen...@gmail.com<mailto:dpsen...@gmail.com>>
Sent: Saturday, August 20, 2016 2:47:52 PM
To: Log4NET Dev
Cc: Stefan Bodewig
Subject: Re: Proposal - log4net extensions pacakge for ASP.NET<http://ASP.NET> 
Core

That would once more bring up the discussion of taking over the ownership of 
the nuget package.

On 20 Aug 2016 4:43 p.m., "Dangling Pointer" 
<danglingpoin...@outlook.com<mailto:danglingpoin...@outlook.com>> wrote:

Thanks Stefan!

I am working on extensions package. We need a new version of log4net released 
on NuGet which support .Net Standard. https://www.nuget.org/packages/log4net/. 
Can you please release v3 soon? It can be the final RTM or beta / RC. All that 
matters is it is consumable as a pacakage dependency to extensions. :)

Thanks again!

From: Stefan Bodewig <bode...@apache.org<mailto:bode...@apache.org>>
Sent: Thursday, August 18, 2016 4:16:11 AM
To: Dangling Pointer
Cc: log4net-dev@logging.apache.org<mailto:log4net-dev@logging.apache.org>
Subject: Re: Proposal - log4net extensions pacakge for ASP.NET<http://ASP.NET> 
Core

On 2016-08-15, Dangling Pointer wrote:

> Placing the extension under extensions directory of log4net repo would
> work as well. :)

Cool, patches welcome :-)

Seriously, I'm currently spending the little development time I have
available on trying to get the release process working so that it
includes the .NET Core assembly. Any help - not only with the extension
package - is really appreciated.

Stefan

Re: Proposal - log4net extensions pacakge for ASP.NET Core

2016-08-20 Thread Dangling Pointer

I am unaware about ownership discussion. Is it so that NuGet package is not 
owned by the repo maintainers?

From: Dominik Psenner <dpsen...@gmail.com>
Sent: Saturday, August 20, 2016 2:47:52 PM
To: Log4NET Dev
Cc: Stefan Bodewig
Subject: Re: Proposal - log4net extensions pacakge for ASP.NET Core

That would once more bring up the discussion of taking over the ownership of 
the nuget package.

On 20 Aug 2016 4:43 p.m., "Dangling Pointer" 
<danglingpoin...@outlook.com<mailto:danglingpoin...@outlook.com>> wrote:

Thanks Stefan!

I am working on extensions package. We need a new version of log4net released 
on NuGet which support .Net Standard. https://www.nuget.org/packages/log4net/. 
Can you please release v3 soon? It can be the final RTM or beta / RC. All that 
matters is it is consumable as a pacakage dependency to extensions. :)

Thanks again!

From: Stefan Bodewig <bode...@apache.org<mailto:bode...@apache.org>>
Sent: Thursday, August 18, 2016 4:16:11 AM
To: Dangling Pointer
Cc: log4net-dev@logging.apache.org<mailto:log4net-dev@logging.apache.org>
Subject: Re: Proposal - log4net extensions pacakge for ASP.NET<http://ASP.NET> 
Core

On 2016-08-15, Dangling Pointer wrote:

> Placing the extension under extensions directory of log4net repo would
> work as well. :)

Cool, patches welcome :-)

Seriously, I'm currently spending the little development time I have
available on trying to get the release process working so that it
includes the .NET Core assembly. Any help - not only with the extension
package - is really appreciated.

Stefan

Re: Proposal - log4net extensions pacakge for ASP.NET Core

2016-08-14 Thread Dangling Pointer

Hello Stefan,

Placing the extension under extensions directory of log4net repo would work as 
well. :)

BR

From: Stefan Bodewig <bode...@apache.org>
Sent: Sunday, August 14, 2016 6:21:09 PM
To: log4net-dev@logging.apache.org
Subject: Re: Proposal - log4net extensions pacakge for ASP.NET Core

On 2016-08-14, Dangling Pointer wrote:

> ASP.NET Core has a pluggable logging infrastructure which a couple of
> known providers are supporting:
> https://github.com/aspnet/Logging/blob/dev/README.md#providers

> Here is the documentation:
> https://docs.asp.net/en/latest/fundamentals/logging.html

> It would be very much appreciated if we get an official repo for this
> extension https://github.com/apache/log4net.Extensions.Logging similar
> to https://github.com/NLog/NLog.Extensions.Logging, now that log4net
> is already compatible with .NET Core.

This would certainly fit well within the project.

Does it have to be a separate repo? Wouldn't be a separate assembly
somewhere under
https://svn.apache.org/repos/asf/logging/log4net/trunk/extensions/
(mirrored as https://github.com/apache/log4net/tree/trunk/extensions )
be enough?

Stefan

Re: String Equality Comparison, Broken Tests and .NET-1.x

Re: String Equality Comparison, Broken Tests and .NET-1.x

Re: Questions About the .NET Core Build

Re: Proposal - log4net extensions pacakge for ASP.NET Core

Re: Proposal - log4net extensions pacakge for ASP.NET Core

Re: Proposal - log4net extensions pacakge for ASP.NET Core

6 matches

Site Navigation

Mail list logo

Footer information