Nlog: Exception Renderer not showing line numbers

[LordZZT]

NLog version: 4.6.8

Platform: .NET Framework 4.6.1

Current NLog config (xml or C#, if relevant)

<target name="dumpFile" type="File"
            networkWrites="true"
            concurrentWrites="true"
            enableArchiveFileCompression="true"

            fileName="${var:DumpDir}${environment-user}_dump.log"
            archiveFileName="${var:DumpDir}\Archive\${environment-user}_dump_{####}.zip"
            archiveEvery="Day"
            archiveNumbering="Date"
            archiveDateFormat="yyyy-MM-dd"

            layout="[PID ${processid}|${longdate}|${level:uppercase=true}|${logger}]${message}${onexception:${newline}${exception:format=tostring}}"/>

• What is the current result?

System.NullReferenceException: Object reference not set to an instance of an object.
   at SimpleIni.IniBuilder.ReadLine(String line)
   at SimpleIni.fromStrings(String[] lines)
   at Program.Main()

• What is the expected result?

System.NullReferenceException: Object reference not set to an instance of an object.
   at SimpleIni.IniBuilder.ReadLine(String line) in \SimpleIni.cs:line 119
   at SimpleIni.fromStrings(String[] lines) in \TestWinForm\SimpleIni.cs:line 37
   at Program.Main() in \TestWinForm\Program.cs:line 24

I just noticed that using the layout renderer ${exception:format=tostring} does not show line numbers. Is this the intended result? And if so is there a way I could just apply Exception.ToString() without writing a custom renderer?

[welcome[bot]]

Hi! Thanks for opening your first issue here! Please make sure to follow the issue template - so we could help you better!

[snakefoot]

${exception:format=tostring} returns the same output as calling Exception.ToString()-method. There is no special operations in NLog.

So your real question is why does Exception.ToString()-method does not include symbol-information such as filenames and line-numbers?

Symbol-information lives in the symbol-files with the PDB-file-extension. They must be deployed together with your application or else symbol information will not be available when exceptions are thrown.

Microsoft introduced a new portable PDB-file-format. That is only support by Net472- and NetCore2-applications. If your application-build is using the new portable-PDB-format, and you are not using the latest framework, then symbol information will also not be available.

Anyway think you will get more response on StackOverflow about how to fix symbol-lookup so Exception.ToString() will starting working. When you have fixed that, then NLog will automatically show the wanted source-file and line-numbers.

[LordZZT]

Very good point, I may be barking up the wrong tree.
However! The way these examples were generated were actually from the same log event in the same build. Specifically by doing log.Error(exception, "Error! {msg}", exception.ToString()); So I'm not entirely sure this is the case.

[snakefoot]

Yes it is strange that your explicit call to exception.ToString() produces one output, but when NLog calls the same method, then it is different result.

Using NLog in my own applications for exception-logging, and I don't have the issue with NLog stripping away symbol-information like source-code and line-numbers.

Are you able to create a small project that reproduces the issue, that you can attach?

[LordZZT]

I can later today, and I will follow up

[LordZZT]

I confirmed after creating a simple project if I were to only use the nlog packages the error does not persist.

I have located the source of the confusion, and that is the "MetroFramework" package.

With this package installed it will omit the line numbers only from the ${message:withException=true} or ${exception:format=tostring} renderers.

Here is the Project WindowsFormsApp1.zip
I'm aware that this is a problem caused by a separate package, however it may still be relevant to look into. Otherwise I will close this issue

[snakefoot]

@LordZZT If you have the time to investigate what is going on, then you are very welcome to check.

But if not then you should just close the issue.

[304NotModified]

Closing this as external