logging-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominik Psenner <dpsen...@gmail.com>
Subject Re: [log4net] release 2.0.9
Date Sun, 21 Jan 2018 10:57:29 GMT
On 21 Jan 2018 11:28 a.m., "Stefan Bodewig" <bodewig@apache.org> wrote:

On 2018-01-20, Dominik Psenner wrote:

> I have looked at the assert that fails. For one there's a comment on it
> saying that "on linux locking seems to not behave as one would expect".
> Second the assert is wrapped in an #if !MONO || MONO_3_5 || MONO_4_0. Note
> that this all comes from my memory and there might be an error here or
> there. It however indicates a long known but badly documented issue
> to how log4net behaves on linux.

Maybe, yes. See the other thread for my investigation so far. The github
issue I've linked and the source code for the Unix implementation of
FileStream state that FileShare.None is the only thing that works on
Unix at all, all other options get translated to "share freely"
internally. Unfortunately I haven't seen this documented for .NET
Standard in any place so far.

So we could do FileShare.None when we detect that we run on linux. What do
you think?

> I really have a bad feeling to release something like that now that
> netstandard has become a supported framework and therefore log4net will
> most likely run more on linux machines.

I understand this, but as far as locking of files goes there isn't
anything we can do.

> How about if we configure ci to run our tests for both netstandard and
> on linux and windows?

I'm not sure we've got Windows slaves running either Mono or .NET
Standard (and if so, probably not 1.x). Maybe the Windows slaves can run
Docker themselves, then we might be able to use the "dotnet" Windows
server images available from dockerhub.

We can start small and work us through the ranks one by one.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message