search

luigiberrettini / NLog.Targets.Syslog

A Syslog server target for NLog
Other
71 stars 46 forks source link

Improper dependency handling with .NET Framework application #308

Closed JayToltTech closed 1 year ago

JayToltTech commented 2 years ago

Bug description

Not getting Syslog output after updating to NLog 5 & Syslog 6.3 or 7.0.

Expected behavior Syslog to continue working after update

Actual behavior Rest of NLog targets are working, but syslog target has stopped.

To reproduce Use NLog.Targets.Syslog from a .NET Framework app.

Additional context

I built my own fork of NLog.Targets.Syslog so I could attach a debugger to investigate. I turned on NLog.InternalLogging and I see:

2022-09-26 09:49:30.8855 Info Validating config: Targets=6, ConfigItems=78 Exception thrown: 'System.IO.FileNotFoundException' in NLog.Targets.Syslog.dll 2022-09-26 09:49:31.0730 Error SyslogTarget([unnamed]): Exception in Initialize Exception: System.IO.FileNotFoundException: Could not load file or assembly 'Polly.Contrib.WaitAndRetry, Version=1.0.0.0, Culture=neutral, PublicKeyToken=17ed651729209acc' or one of its dependencies. The system cannot find the file specified. File name: 'Polly.Contrib.WaitAndRetry, Version=1.0.0.0, Culture=neutral, PublicKeyToken=17ed651729209acc' at NLog.Targets.Syslog.MessageSend.BackoffDelayProvider..ctor(Int32 maxRetries, ConstantBackoffConfig config) at NLog.Targets.Syslog.MessageSend.BackoffDelayProvider.<>c.<.cctor>b3_0(RetryConfig retryConfig) at NLog.Targets.Syslog.MessageSend.BackoffDelayProvider.FromConfig(RetryConfig retryConfig) at NLog.Targets.Syslog.MessageSend.MessageTransmitter..ctor(Layout server, Int32 port, RetryConfig retryConfig) at NLog.Targets.Syslog.MessageSend.Tcp..ctor(TcpConfig tcpConfig, RetryConfig retryConfig) at NLog.Targets.Syslog.MessageSend.MessageTransmitter.<>c.<.cctor>b__10_1(MessageTransmitterConfig messageTransmitterConfig) at NLog.Targets.Syslog.MessageSend.MessageTransmitter.FromConfig(MessageTransmitterConfig messageTransmitterConfig) at NLog.Targets.Syslog.AsyncLogger..ctor(Layout loggingLayout, EnforcementConfig enforcementConfig, MessageBuilder messageBuilder, MessageTransmitterConfig messageTransmitterConfig) at NLog.Targets.Syslog.SyslogTarget.b21_0(Int32 i) at System.Linq.Enumerable.WhereSelectEnumerableIterator2.MoveNext() at System.Linq.Buffer1..ctor(IEnumerable1 source) at System.Linq.Enumerable.ToArray[TSource](IEnumerable1 source) at NLog.Targets.Syslog.SyslogTarget.Init() at NLog.Targets.Syslog.SyslogTarget.InitializeTarget() at NLog.Targets.Target.Initialize(LoggingConfiguration configuration)

JayToltTech commented 2 years ago

Investigating to see if I can fix and submit a PR.

JayToltTech commented 2 years ago

Not sure what the proper fix is here. I found that if I manually added Polly.Contrib.WaitAndRetry to my NuGet dependencies for my .NET Framework 4.8 Exe project, the nlog.targets.syslog logging worked.

I don't see anything obvious in this project to change to enable dependency auto handling...

JayToltTech commented 2 years ago

I see polly.contrib.waitandretry as a proper nuget dependency in my telemetry assembly (App.Telemetry.Dll), but the polly dll doesn't appear in the bin directory when built. Ergo, it's also not in the App.Exe (which dependes on App.Telemetry.Dll) bin directory.

I rebuilt NLog.Targets.Syslog adding back in net480 to target framework, in case removing .NET Framework was messing with the dependency mgmt (but NLog.Targets.Syslog was otherwise working fine from .NET Framework I suppose due to the .NET Standard 2.0 support). This fixed the issue.

It seems that if NLog.Targets.Syslog is built for .NET Standard 2.0, the assembly itself works but the Nuget dependencies don't propagate properly. Adding net480 back into the target frameworks for the project fixes the issue.

luigiberrettini commented 1 year ago

Despite the .NET Framework is said to be an implementation of .NET Standard the reality is that libraries have to be built for it to work properly.

The support for .NET Framework was dropped and there is no plan to reintroduce it nor to investigate issues related to it.

.NET Framework users have the following options:

JayToltTech commented 1 year ago

With respect, forking the project into .NET 5/6/7 & .NET Framework doesn't do the community a service. I'm sure you can envision the issues with having to find the 'right' Nuget package.

The parent library, NLog, supports .NET Framework. I can understand wanting to reduce the scope of what you maintain, but I have done the legwork to investigate this and submit what I think is an appropriate support patch for you.

For existing projects under maintenance, "move them to .NET 5 or later" can be a problem. I know, I've tried.