Castle.Services.Logging.EventLogIntegration for Windows EventLog

[snakefoot]

Removed nuget-dependency System.Diagnostics.EventLog from the Castle.Core-package as it is Windows-only (And will explode in your face when used on other platforms).

Makes Castle.Core free of extra nuget-dependencies for net462 + netstandard2.1 + net8.0 (essence of core)

People using Windows and depend on the DiagnosticsLogger just have to add an additional nuget-package to their project.

Could consider changing net8.0 to net8.0-windows for Castle.Services.Logging.EventlogIntegration and remove the direct nuget-dependency.

[stakx]

@snakefoot, it's been a while. I've finally found a moment to look at this. Sorry for letting you wait so long.

Code conflicts resulting from the merge of #696 aside, I think we should first come to a decision on the future of Castle's logging facilities in general (see #408) before we proceed here. As long as we haven't decided for or against deprecating the logging facilities as a whole, I'd prefer not to invest too much time in them... including this PR.

I do agree that it's a bit strange to have almost all bits of a library work on all platforms except this one class, DiagnosticsLogger. But then it's also strange that the System.Diagnostics.EventLog package can even be installed successfully on non-Windows platforms. Even if we offload DiagnosticsLogger into its own package, Linux people can still install that package and have it explode in their faces.

Given these considerations, perhaps it would be much less trouble simply changing DiagnosticsLogger's XML documentation comments to make it clear that it only works on Windows!?

[snakefoot]

Still think Castle.Core should have minimal dependencies, and not drag unnecessary dependencies for all users. Also considering that the Castle.Core-Logging-API is not that relevant after the introduction of Microsoft.Extensions.Logging.

The System.Diagnostics.EventLog-nuget-package can be installed on all platforms. Has a default implementation for non-windows platforms that explodes in your face. Do not think a XML comment will help against that.

[stakx]

@snakefoot, you're making a good argument regarding minimal dependencies, I definitely agree with you there.

(If it were solely up to me, I'd go much further and reduce Castle.Core to just DynamicProxy. But this project traditionally tries very hard not to cause unnecessary breaking changes for downstream users, which I think is a good policy for any infrastructure library. So I'm practicing some restraint there. 🙃)

Maybe introducing an additional logging package really wouldn't be a big deal, even if it ends up being a short-lived intermediate step towards abandoning the logging facilities. (Especially when considering that coming to a conclusion in #408 may be indefinitely held up by the Castle Windsor project, which hasn't seen any active development in a while.)

Let me sleep on this.