Thanks for creating this package. We exclusively use NLog 3 - would it be possible to update the nuget package to implement a binding redirect? We can of course write this ourselves, but other users may spend some time debugging why NLog either invisibly fails, or if you have throwExceptions on, then it crashes.

Thanks!

It would be great if @graffen could create a Travis CI account, shared among mantainers as the one created for AppVeyor

I created PR #108 to provide the build scripts

Having an issue upgrading to version NLog.Targets.Syslog 3.0+ in an ASP.Net project. Made a brand new one for testing, only added this package and its dependancies, received the following error when trying to generate a new MessageBuilderConfig() that appears to be related to either of the RFC configs

System.InvalidOperationException: Sequence contains no matching element
   at System.Linq.Enumerable.First[TSource](IEnumerable`1 source, Func`2 predicate)
   at NLog.Targets.Syslog.Extensions.StackTraceExtensions.EntryAssembly(StackTrace stackTrace)
   at NLog.Targets.Syslog.Settings.UniversalAssembly.EntryAssembly()
   at NLog.Targets.Syslog.Settings.Rfc3164Config..ctor()
   at NLog.Targets.Syslog.Settings.MessageBuilderConfig..ctor()
   at WebApplication1.Controllers.AccountController.Login(String returnUrl) in C:\\Workspace\\TestingApp\\WebApplication\\Controllers\\AccountController.cs:line 75

It would be nice to add the following topics to the GitHub project:

1. logging
2. nlog
3. syslog
4. dotnet
5. library

Any plans to support this?

Ps. You will need a reference to NLog 5 beta then.

Multi-line log messages don't seem to be splitting into multiple messages. Instead, the receive end gets one big message with all lines concatenated.

Currently, ReplaceKnownValuePolicy makes use of the static Regex.Replace method with a readonly searchFor value. Considering the guidance in 'Best Practices for Regular Expressions in the .NET Framework' (https://msdn.microsoft.com/en-us/library/gg578045(v=vs.110).aspx), it would be more performant for the ReplaceKnownValuePolicy class to have instantiate a private (compiled) Regex() instance upon construction and to use this within the Apply method.

Provide a way to disable internal logger calls and message creation when the internal logger / that level of internal logging is disabled.

Add support of RFC5848 standard implementation to enable signed syslog messages.

I'm using a NuGet package called NLog.Targets.Syslog - which appears to be a fork of this repo (see https://github.com/joefitzgerald/NLog.Targets.Syslog). However - I'd like to use TCP support, which I see has been implemented here.

Any chance of publishing this version as a NuGet? I wonder if that's the reason @joefitzgerald forked the project...

I'm not sure which details to provide, but I have a syslog server running on System A and my app is running on System B. I'm using UDP to log.

If System A is in the middle of coming online when my app starts on System B, I don't see any syslog messages. If I restart my application or the entire System B, I see messages as expected.

Is this expected or intentional behavior? Is there a way around it?

The latest version on nuget - 2.0.5325.30493 - seems to have a significant bug, where multi-line messages get submitted multiple times to the syslog server, one for each line. (This cost me plenty with papertrail, before I figured it out.) I'm not sure where it got fixed, but it doesn't seem to be present in the latest version in the git repo, which I think is (barely) subsequent to the version up on nuget. Would it be possible to update nuget?

Hi @graffen, it would be nice if you could configure AppVeyor (I do not have access to repo settings).

Thanks!

Im using NLog.Targets.Syslog to log messages to Kiwi Syslog. recently i found that this target type is consuming lot of memory.

Nlog.config code

<target xsi:type="sl:Syslog" name="syslogForImporter">
      
		<sl:layout xsi:type="SimpleLayout" text=" NewSVC: ${date:format=yyyy-MM-ddTHH\:mm\s.fff} ${message}${exception:format=ToString,StackTrace}" />

		<sl:enforcement>
        <sl:splitOnNewLine>true</sl:splitOnNewLine>
        <sl:transliterate>true</sl:transliterate>
        <sl:replaceInvalidCharacters>true</sl:replaceInvalidCharacters>
        <sl:truncateFieldsToMaxLength>true</sl:truncateFieldsToMaxLength>
        <sl:truncateMessageTo>1024</sl:truncateMessageTo>
      </sl:enforcement>
      <sl:messageCreation>
        <!--Facility as log audit-->
        <sl:facility>Audit</sl:facility>
        <sl:rfc>Rfc3164</sl:rfc>
        <sl:rfc3164 hostname="${machinename}" tag="${logger}"  />
      </sl:messageCreation>
      <sl:messageSend>
        <sl:protocol>UDP</sl:protocol>
        <sl:udp>
          <sl:server>10.20.30.40</sl:server>
          <sl:port>514</sl:port>
        </sl:udp>

      </sl:messageSend>
    </target>

After disabling the target rule for syslog, the memory utilization decreased drastically.

Can someone help me out with this issues. Im using c#, NLog V4.4.12,NLog.Targets.Syslog V4.0.0.0

Hi, I use NLog.Targets.Syslog to send log into graylog.

I see the graylog count tcp connections as below

Active connections: 0 (471,094 total)

It seems NLog.Targets.Syslog will open a new tcp connection to send every message.

Is it a problem that the inactive connections will not be closed?

The schema at http://nlog-project.org/schemas/NLog.Targets.Syslog.xsd is no longer valid after your last update which changed the way TLS works. This is particularly troublesome because there is documentarion around the web that uses the prior way (for example: http://help.papertrailapp.com/kb/configuration/nlog-net-logging/).

I understand it's probably not your responsability, but thought I should let you know. It took me a while to make the library work because of this :P

Nuget's latest version (2.0.5164.28270) has a critical bug. Thread dependent data is being lost when message lines are being splitted. It was fixed in commit 387dd2f. Thanks.

Semantic versioning

3.0.2(-<prerelease>)(+<buildnumber>)

AssemblyInfo versioning

AssemblyVersion
3.0.0

AssemblyFileVersion
3.1.0.<APPVEYOR_BUILD_NUMBER>

AssemblyInformationalVersion
3.1.0(-<prerelease>)

Info

It could be useful to rely on AppVeyor cmdlets:

Update-AppveyorBuild -Version "$major.$minor.$patch.$env:APPVEYOR_BUILD_NUMBER"
Set-AppveyorBuildVariable -Name <string> -Value <string>

Maybe it is sufficient to perform AssemblyInfo patching in AppVeyor:

assembly_info:
    patch: true
    file: MyVersion.cs
    assembly_version: '$(assembly_version)'
    assembly_file_version: '$(appveyor_build_version)'
    assembly_informational_version: '$(assembly_info_version)'

Links

• http://semver.org
• https://github.com/StevenThuriot/Snippets/blob/master/AppVeyor/Patch%20Assembly%20Version.ps1
• https://www.appveyor.com/docs/build-worker-api/#set-environment-variable
• https://gist.github.com/FeodorFitsner/e038821e3e46e3df0e8f
• http://help.appveyor.com/discussions/problems/5926useenvironmentvariableinversion
• http://stackoverflow.com/questions/826777/how-to-have-an-auto-incrementing-version-number-visual-studio
• http://stackoverflow.com/questions/3279235/net-assemblyname-version-build-versus-revision
• http://stackoverflow.com/questions/64602/what-are-differences-between-assemblyversion-assemblyfileversion-and-assemblyin

Notice about major.minor.build.revision

BUILD
Refers to the build number in a software product, not the number of times you run a build!
Different build numbers can be used:

• when source code changes for hotfix updates of a major.minor.{build - 1} version (build number increased by 1)
• when source code is the same and processor/platform/compiler change

REVISION
Refers to the revision number in a software product, not not the number of times you run a build!
Different revision numbers can be used:

• when source code changes hotfix updates of a major.minor.build.{revision - 1} version (revision number increased by 1)
• only when assemblies are fully interchangeable with other assemblies having a different revision number

Task list

• Use the right attributes in AssemblyInfo.cs
• Use AssemblyInformationalVersion to retrieve version during build script execution
• Use Update-AppveyorBuild to set AppVeyor build version on the basis of AssemblyInfo version
• Patch AssemblyInfo.cs, on AppVeyor build, changing only AssemblyFileVersion

As suggested by @snakefoot in #56 use internal logger this way:

InternalLogger.Debug("Successfully sent message '{0}'", logEventMsgSet);

The Syslog-target includes its own Async-Wrapper using the Task-system.

The Syslog-target should capture the context of the logging-thread, instead of capturing the context of the async Task (Ex. thread-id, callsite, etc.)

This is done by adding the following bold line:

protected override void Write(AsyncLogEventInfo asyncLogEvent)
{
MergeEventProperties(asyncLogEvent.LogEvent);
PrecalculateVolatileLayouts(logEvent.LogEvent);
var asyncLoggerId = asyncLogEvent.LogEvent.SequenceID % Enforcement.MessageProcessors;
asyncLoggers[asyncLoggerId].Log(asyncLogEvent);
}

Iam trying to log to the papertrail systems using Nlog and NLog.Targets.Syslog and somehow Nlog fails to load the target from the Nlog.config when i call

Logger logger = LogManager.GetCurrentClassLogger();

and throws the exception Object reference not set to an instance of an object.

at NLog.Targets.Syslog.Settings.Rfc3164Config..ctor()
   at NLog.Targets.Syslog.Settings.MessageBuilderConfig..ctor()
   at NLog.Targets.Syslog.SyslogTarget..ctor()
Stacktrace
at NLog.Config.XmlLoggingConfiguration.Initialize(XmlReader reader, String fileName, Boolean ignoreErrors)
   at NLog.Config.XmlLoggingConfiguration..ctor(String fileName, Boolean ignoreErrors, LogFactory logFactory)
   at NLog.LogFactory.LoadLoggingConfiguration(String configFile)
   at NLog.LogFactory.get_Configuration()
   at NLog.LogFactory.GetLogger(LoggerCacheKey cacheKey)
   at NLog.LogFactory.GetLogger(String name)
   at NLog.LogManager.GetCurrentClassLogger()
   at NLogPaperTrail.Controllers.HomeController.Index() in I:\Temp\Proj\tempsolution\NLogPaperTrail\NLogPaperTrail\Controllers

This is the Nlog.config

<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" autoReload="true"     ThrowExceptions = "true"  >

 <extensions>

       <add assembly="NLog.Targets.Syslog" />
    </extensions>

    <targets>
        <target name="syslog" xsi:type="Syslog" syslogserver="host.papertrailapp.com" port="5677" facility="Local7"/>

   </targets>

    <rules>

     <logger name="*" minLevel="Trace" appendTo="syslog"/>
    </rules>
</nlog>

Can anyone help or provide your suggestions?

Thanks to @codebymatt for #99

https://github.com/graffen/NLog.Targets.Syslog/blob/master/src/NLog.Targets.Syslog/Settings/Rfc5424Config.cs#L46

Assembly.GetEntryAssembly().GetName().Name;

It's not working.

I'm looking to add one or more people as contributors to this project since I don't have a lot of free time to take care of it anymore.
So, those of you that have been submitting PRs lately, if you would like to take over some of the responsibility, I'd be willing to add commit rights to the repo and on Nuget for this package.

It would be nice if we could change the repo description to "A Syslog server target for NLog" that is similar to the assembly description.

I'm trying to change the target from the code, but the Logger keep sending to the old destination.
Here is the code:

var syslogTarget = (NLog.Targets.Syslog.SyslogTarget)LogManager.Configuration.FindTargetByName("SyslogTarget");
syslogTarget.MessageSend.Udp.Server = "127.0.0.1";
LogManager.ReconfigExistingLoggers();
LogManager.Flush();

Note: changing another target (file target) works that way.

Any thoughts?

• Create nuspec file for the target schema
• Update build script
• Update appveyor.yml

When logs are being sent to a syslog endpoint via TCP, that endpoint becomes unavailable (e.g. Service stops or network outage) and then subsequently returns, logs do not get sent to the destination. Restarting the application rectifies this.

Initial analysis is that the interaction with streams within the Tcp::FramingTask and Tcp::WriteAsync methods can cause an unhandled IOException to be raised upon comms failures. This appears to upset the AsyncLogger class such that the ProcessQueueAsync method is nolnger invoked (I guess that the unhandled exception is causing the Task hosting the ProcessQueueAsync method to fail).

Proposed solution is to have specific IOException handling within these 2 methods, which I'll include on a candidate branch.

As per RFC5234 [https://tools.ietf.org/html/rfc5424#section-6] the time fraction should have 1 to 6 digit. Time formated by the target uses DateTime.ToString("o") which produces a 7 digits time fraction.

It has been reported by one of our customer to be incompatible with their syslog client.

The latest v3.1.0 release of NLog.Targets.Syslog seems to form a new TCP and TLS connection for each individual log message. (Confirmed with a tcpdump.) This limits the maximum log rate to about 1 message per second, unless we start adding extra messageProcessors.

Upon further investigation, the older v2 release seems to do roughly the same thing, but performance can be improved by wrapping it in either an AsyncWrapper or BufferingWrapper. I assume that's because these wrappers deliver multiple events simultaneously, and then NLog.Targets.Syslog can share a single connection for the whole batch.

These wrappers aren't needed (and don't help) for v3, since the target is already asynchronous. The new target accepts each batch immediately, but then requeues them internally, and fires up a new TCP connection for each one.

After some more testing, I just realized that setting connectionCheckTimeout to 0 solves the issue, so perhaps #74 is the issue?

• Update license file
• Update documentation with relation to the license
• Update copyright in AssemblyInfo.cs
• Update copyright in nuspec files
• Add copyright and license info to all source files

As for copyright, consider using a date range and including the contributors URL

See #66 for more information

My w3wp service terminated unexpectedly this morning. This is what I'm seeing in Event Viewer:

Application: w3wp.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.InvalidOperationException
   at System.Threading.Tasks.TaskCompletionSource`1[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].SetException(System.Exception)
   at NLog.Targets.Syslog.Extensions.TaskExtensions+<>c__DisplayClass5_0`1[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].<Callback>b__0(System.IAsyncResult)
   at System.Net.LazyAsyncResult.Complete(IntPtr)
   at System.Net.LazyAsyncResult.ProtectedInvokeCallback(System.Object, IntPtr)
   at System.Net.Security._SslStream.StartWriting(Byte[], Int32, Int32, System.Net.AsyncProtocolRequest)
   at System.Net.Security._SslStream.WriteCallback(System.IAsyncResult)
   at System.Net.LazyAsyncResult.Complete(IntPtr)
   at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
   at System.Net.ContextAwareResult.Complete(IntPtr)
   at System.Net.LazyAsyncResult.ProtectedInvokeCallback(System.Object, IntPtr)
   at System.Net.Sockets.BaseOverlappedAsyncResult.CompletionPortCallback(UInt32, UInt32, System.Threading.NativeOverlapped*)
   at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32, UInt32, System.Threading.NativeOverlapped*)

No idea if this is a problem with Syslog. There are other interesting entries in Event Viewer but they don't give a whole lot. For example:

An unhandled exception occurred and the process was terminated.

Application ID: DefaultDomain

Process ID: 2344

Exception: System.AppDomainUnloadedException

Message: Attempted to access an unloaded AppDomain.

StackTrace: 

and also:

Faulting application name: w3wp.exe, version: 10.0.14393.0, time stamp: 0x57899b8a
Faulting module name: KERNELBASE.dll, version: 10.0.14393.1358, time stamp: 0x59327897
Exception code: 0xe0434352
Fault offset: 0x0000000000033c58
Faulting process id: 0x928
Faulting application start time: 0x01d2f57f4b72a237
Faulting application path: c:\windows\system32\inetsrv\w3wp.exe
Faulting module path: C:\Windows\System32\KERNELBASE.dll
Report Id: fd3dce6e-120f-4827-9320-b5fd56dfb342
Faulting package full name: 
Faulting package-relative application ID: 

Please close if you think this is unrelated to Syslog extension.

There are a lot of projects adopting the MIT license.
Moreover I looked at NLog and other projects/NuGet packages: most times copyright is not set in AssemblyInfo.cs and *.nuspec files, but is present in the source code.

@graffen, @304NotModified I would be happy to understand rules or just your idea/position on the following questions.

1. Should we adopt it or stay with Apache or use the BSD used by NLog since we depend on it?
2. Should we remove copyright from AssemblyInfo.cs attributes and *.nuspec?
3. Which people should be listed in the source file header copyright notice: all contributors, some or only the original creator of the repo?
4. Is the copyright always of the contributor who commits or shared between him and the repo owner or transferred from the contributor to the repo owner?

Thank you!

NuGet packages are correctly versioned, but assemblies are not:

It seems that the version passed to build scripts (tag without the v) does not have any effect on assembly information.

v5.0.0-beta-01 is affected by this bug.

Hi Jesper,

We're trying to support NLog as a sender for our hosted logging service, and encountering a somewhat strange issue. Newlines show up as the string "1512" since the string is being encoded in ASCII (https://github.com/graffen/NLog.Targets.Syslog/blob/master/src/NLog.Targets.Syslog/NLog.Targets.Syslog.cs#L349) and 15 is the ASCII character code for CR, 12 for LF (in octal).

The syslog RFCs don't define a specific way to handle newlines (or even mandate that senders or receivers allow them), and implementations behave differently, so there's nothing inherently wrong with that.

However, it made me wonder whether you've tried messages containing newlines (and meant to support them), and if so, whether this was an intentional decision or just the way that Encoding.ASCII.GetBytes happened to encode it.

We want to make sure that our receiver expects that input and displays them as newlines. If 15, 12 is intentional, we'll plan around that.

BTW, let me know if you have any questions about the syslog protocol or mechanics. I noticed in your blog you asked for feedback last year, and we have a lot of experience in that area (github.com/papertrail/remote_syslog, https://github.com/papertrail/syslog_protocol, and others). Always happy to try to answer questions or help with testing.

And thanks for a neat target, too. Cheers,

Troy

We have more than one application running on a server. They are both using NLog for logging. We need the ability to specify something in the config file that will show in the log message. Otherwise, we can't tell which application actually logged the message.

Rfc3164 do not support utf8.

https://github.com/graffen/NLog.Targets.Syslog/blob/master/src/NLog.Targets.Syslog/MessageCreation/Rfc3164.cs#L48

Is this by design?

SD elements are currently being sent with two left brackets, causing the id and params to be misinterpreted by some syslog implementations.

More details and a proposed fix are in PR #40

Hello,

I'm trying to use fromEventProperties to automatically create structuredData, but it doesn't seem to be working and it doesn't seem to be throwing an error.

Here's my config:

<?xml version="1.0" encoding="utf-8" ?>
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:sl="http://www.nlog-project.org/schemas/NLog.Targets.Syslog.xsd" throwExceptions="true">
  <targets>
    <target xsi:type="ColoredConsole" name="console">
      <layout xsi:type="SimpleLayout" text="${message}${exception:format=ToString,StackTrace}" />
    </target>
    <target xsi:type="sl:Syslog" name="syslog">
      <sl:layout xsi:type="SimpleLayout" text="${message}${exception:format=ToString,StackTrace}" />
      <sl:enforcement>
        <sl:splitOnNewLine>false</sl:splitOnNewLine>
        <sl:transliterate>false</sl:transliterate>
        <sl:replaceInvalidCharacters>false</sl:replaceInvalidCharacters>
        <sl:truncateFieldsToMaxLength>true</sl:truncateFieldsToMaxLength>
        <sl:truncateMessageTo>1024</sl:truncateMessageTo>
      </sl:enforcement>
      <sl:messageCreation>
        <sl:facility>Local4</sl:facility>
        <sl:rfc>rfc5424</sl:rfc>
        <sl:rfc5424>
          <sl:hostname xsi:type="SimpleLayout" text="${machinename}" />
          <sl:appName xsi:type="SimpleLayout" text="${processname}" />
          <sl:procId xsi:type="SimpleLayout" text="${processid}" />
          <sl:msgId xsi:type="SimpleLayout" text="${threadid}" />
          <sl:structuredData>
            <sl:fromEventProperties xsi:type="SimpleLayout" text="${event-properties:item=structuredData}" />
          </sl:structuredData>
        </sl:rfc5424>
      </sl:messageCreation>
      <sl:messageSend>
        <sl:protocol>UDP</sl:protocol>        
        <sl:udp>
          <sl:server>syslogserver</sl:server>
          <sl:port>514</sl:port>
        </sl:udp>
      </sl:messageSend>
    </target>
  </targets>
  <rules>
    <logger name="*" minlevel="Debug" writeTo="console" />
    <logger name="*" minlevel="Debug" writeTo="syslog" />
  </rules>
</nlog>

Here's how I'm logging data:

LogEventInfo message = new LogEventInfo(LogLevel.Info, "", String.Format("Downloaded {0} in {1:0.0} seconds. ({2} bytes at {3:0.00} kbps)",
                file.FileName,
                downloadDuration,
                downloadSize,
                (downloadSize / 1024) / downloadDuration
                ));

            message.Properties["fileName"] = file.FileName;
            message.Properties["fileSize"] = downloadSize;
            message.Properties["mediaDuration"] = audioDuration;
            message.Properties["downloadDuration"] = downloadDuration;
            message.Properties["downloadSpeed"] = (downloadSize / 1024) / downloadDuration;
            logger.Log(message);

When I look at the message being sent it doesn't seem to include a StructuredData section at all.

Is this a bug, or have I done something wrong here.

Many Thanks!

-Z

Tcp message send should support client certificates:

sslStream.AuthenticateAsClient(Server, clientCerts, SslProtocols.Tls12, false)

PR #83 by @MUzzell

Version 1.0.0 works fine while version 1.1.0.37957 throws this error:

System.NotSupportedException: Parameter layout not supported on Syslog
  at NLog.Internal.PropertyHelper.SetPropertyFromString (System.Object o, System.String name, System.String value, NLog.Config.ConfigurationItemFactory configurationItemFactory) [0x00000] in <filename unknown>:0
  at NLog.Config.XmlLoggingConfiguration.ConfigureObjectFromAttributes (System.Object targetObject, NLog.Config.NLogXmlElement element, Boolean ignoreType) [0x00000] in <filename unknown>:0
  at NLog.Config.XmlLoggingConfiguration.ParseTargetElement (NLog.Targets.Target target, NLog.Config.NLogXmlElement targetElement) [0x00000] in <filename unknown>:0
  at NLog.Config.XmlLoggingConfiguration.ParseTargetsElement (NLog.Config.NLogXmlElement targetsElement) [0x00000] in <filename unknown>:0
  at NLog.Config.XmlLoggingConfiguration.ParseNLogElement (NLog.Config.NLogXmlElement nlogElement, System.String baseDirectory) [0x00000] in <filename unknown>:0
  at NLog.Config.XmlLoggingConfiguration.ParseTopLevel (NLog.Config.NLogXmlElement content, System.String baseDirectory) [0x00000] in <filename unknown>:0
  at NLog.Config.XmlLoggingConfiguration.Initialize (System.Xml.XmlReader reader, System.String fileName, Boolean ignoreErrors) [0x00000] in <filename unknown>:0
  --- End of inner exception stack trace ---
  at NLog.Config.XmlLoggingConfiguration.Initialize (System.Xml.XmlReader reader, System.String fileName, Boolean ignoreErrors) [0x00000] in <filename unknown>:0
  at NLog.Config.XmlLoggingConfiguration..ctor (System.String fileName) [0x00000] in <filename unknown>:0
  at NLog.LogFactory.get_Configuration () [0x00000] in <filename unknown>:0
  at NLog.LogFactory.GetLogger (NLog.LoggerCacheKey cacheKey) [0x00000] in <filename unknown>:0
  at NLog.LogFactory.GetLogger (System.String name) [0x00000] in <filename unknown>:0
  at NLog.LogManager.GetLogger (System.String name) [0x00000] in <filename unknown>:0

Enable socket low level keep-alive configuration

Can your target be used with the nlog async wrappers?

Noticed the following new behavior with v3:

• New configuration syntax. May be worth clarifying whether or not NLog v2 is still supported, or if everyone should immediately switch to the latest v3. Also, maybe it's just me, but this makes things seem more complicated than they really are, especially when compared to its predecessor. =)
• My "Hello World" test program needs an explicit sleep at the end. NLog v2 seemed to be a bit more synchronous, at least for the initial TCP connection and TLS negotiation. My assumption was that, if we wanted it to be asynchronous, we'd put it in an AsyncWrapper.

I like the new syntax, now that I'm used to it. But the changes seemed to come out of nowhere, for those of us not keeping up on these commits. A brief changelog in the README would probably help, even if it just says that the v2 syntax won't work with v3. And possibly something about whether AsyncWrapper is no longer (or never was) needed.

when I installed version 2.1.5893.18660 every thing was ok,
but now upgrade to 2.1.6015.35897, It's fail to send log.

We are using NLog.Targets.Syslog version 4.0.0 to log approximately 20-30Mb of log entries a day from half a dozen or so machines.

However, we are regularly seeing a System.IO.IOException exception in the NLog internalLogFile with the message "Unable to write data to the transport connection" and an inner exception of type System.Net.Sockets.SocketException with the message "An established connection was aborted by the software in your host machine"

Here's an example stack trace:

2017-08-11 08:35:39.0636 Warn Task faulted Exception: System.IO.IOException: Unable to write data to the transport connection: An established connection was aborted by the software in your host machine. ---> System.Net.Sockets.SocketException: An established connection was aborted by the software in your host machine
   at System.Net.Sockets.Socket.BeginSend(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags, AsyncCallback callback, Object state)
   at System.Net.Sockets.NetworkStream.BeginWrite(Byte[] buffer, Int32 offset, Int32 size, AsyncCallback callback, Object state)
   --- End of inner exception stack trace ---
   at System.Net.Sockets.NetworkStream.BeginWrite(Byte[] buffer, Int32 offset, Int32 size, AsyncCallback callback, Object state)
   at System.Net.Security._SslStream.StartWriting(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security._SslStream.ProcessWrite(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security._SslStream.BeginWrite(Byte[] buffer, Int32 offset, Int32 count, AsyncCallback asyncCallback, Object asyncState)
   at NLog.Targets.Syslog.Extensions.TaskExtensions.SafeFromAsync[TArg1,TArg2,TArg3](TaskFactory taskFactory, Func`6 beginMethod, Action`1 endMethod, TArg1 arg1, TArg2 arg2, TArg3 arg3, Object state)

Is there anything you can think of we can do to improve the resilience of the connection, or that we might be doing wrong that is causing this issue?

It is very possible for application log entries to include new lines characters such as CR, LF (e.g. Within exception stack traces). From testing NLog.Targets.Syslog with an Ubuntu Rsyslog endpoint, I've observed that the characters get converted to octal representation (015, 016) within the logged text. It is possible to replace these using the ReplaceKnowValuePolicy, but it would be nice to have a specific policy for new lines.