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.

[stakx]

It's entirely possible that the logging facilities will soon disappear completely, but in case that we keep them around, I now agree with you that the Castle.Core package should be freed from the package dependency on System.Diagnostics.EventLog.

Could you please rebase your PR on top of current master and look into the few things I've commented on? You may additionally have to update the ref/ files, too.

[stakx]

I've since converted the solution file to the simpler .slnx format, please edit Castle.Core.slnx instead.

[stakx]

Is this change strictly required for offloading DiagnosticsLogger into a separate project/package? If not (which I suspect), please undo this change.

Same goes for the same change in Castle.Core.Tests.csproj.

[stakx]

In the new Castle.Services.Logging.EventLogIntegration.csproj file, you're using a different condition:

<ItemGroup Condition=" '$(TargetFrameworkIdentifier)' != '.NETFramework' ">
	<PackageReference Include="System.Diagnostics.EventLog" Version="8.0.2" />
</ItemGroup>

Should we perhaps do it the same way here, too?

[stakx]

Please change the year in the first line of the copyright notice from 2004-2022 to 2004-2025 (or 2026, depending on when you get around to touching that file again).

Same goes for the other code files that you're adding/changing.

[stakx]

I think it would make sense to stay in line with the other Castle.Services.Logging.XYIntegration projects and choose a root namespace that is identical to the assembly name, so <RootNamespace>Castle.Services.Logging.EventLogIntegration</RootNamespace> in this case.

[stakx]

This looks unnecessary, this project does not have a Properties/ sub-directory.

[stakx]

As mentioned above, please update the year from 2004-2022 to either 2004-2025 or 2004-2026 (depending on when you get around to doing so).

[stakx]

As mentioned above, I think it would be better to either...:

1. use namespace Castle.Services.Logging.EventLogIntegration (for consistency with other logging integration packages); or
2. or otherwise to preserve the original namespace (for minimal breakage).

IMHO option (1) would be the better one, since DiagnosticsLogger no longer lives in the "core" package, so perhaps the namespace should reflect that.

[stakx]

This is an unrelated change; please revert it.