Update XmlLayoutSchemaLog4j.cs

[dmarlow]

Use prefix and ns to play nice with XmlWriter

[dmarlow]

I re-made the edits as the previous commit had white-space issues. This one is much friendlier.

[Vizehase]

We support this pull request. Without this bugfix, the layout does not work on Win .NET Core 3.1 platform (nothing is actually logged any more), so we had to take this bugfix into an own layout class and redirect our config files to that. Please merge this pull request!

[fluffynuts]

Accepting on the basis of formatting changes only; I don't personally know of the impact so take it on the grounds of the PR and supporting requests as part of an attempt to clean up outstanding pull requests

[fluffynuts]

Please also note that this PR is against the develop branch which is in a state which I can't vouch for, so I've cherry-picked be299bc into master

[StarWars999123]

I highly doubt, that this PR should have been closed. I currently assume, that the RenderLoggingEvent method might have challenges to keep up with this change.
It could be, that the additional log4net element can not be parsed.

[tobylo]

I suspect this change is the reason we no longer get XML logs for our .NET framework services after upgrading from 2.0.12 to 2.0.14. Works for netcoreapp, net5 and net6.

net48 and net461 (the ones I've tried with) results in blank xml files.

[fluffynuts]

@tobylo I've been looking into this as part of another issue - there's a similar situation in the "non-log4j" variant which I had to update for the test app I wrote to work against it since the test app is using dotnet 6. I have updates in the pipeline that use the merged behavior for the NETSTANDARD target only, reverting to the original behavior otherwise, which should solve the problem for both use-cases.

This is an unfortunate case of dotnet breaking compatibility - older XmlWriter.WriteStartElement calls would allow element names with a : in them (ie log4j:event) where dotnet core / 5+ throw an argument exception for this and provide no way to request the original behavior - instead, you have to go all-in on namespacing. I don't know when I'll get a release out because I was working on this to solve another issue (issue claims that there's a circumstance where logs are overwritten instead of rolled, and the example provides uses the other xml layout class). Perhaps it's worthwhile doing a fix release just to get this behavior out? Your thoughts?

[tobylo]

@fluffynuts We haven't noticed being affected by the other issues that were fixed in the .13 and .14 releases, so from our point of view, better roll forward with a proper fix when you have the time to work on it.

But I think it should be added to the release notes that there's a known issue for the combination .net framework and xml log output.

[Aaron-Ritter-IDEXX]

I agree that it would have been helpful to see a mention in the release notes, here. I took an educated guess to click on the link to this PR, and luckily, I was right. It was a good thing we have some unit/integration tests for our logging, as weird as that sounds. https://logging.apache.org/log4net/release/release-notes.html