NLog version: 4.4.5
Platform: .Net 4.0 / .Net 4.5 /
Current NLog config (xml or C#, if relevant)
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.nlog-project.org/schemas/NLog.xsd NLog.xsd"
autoReload="true"
throwExceptions="false"
internalLogLevel="Off" internalLogFile="c:\temp\nlog-internal.log">
<variable name="LogHome" value="${specialfolder:folder=CommonApplicationData}/Bosch/Video Stitcher/log/Wizard"/>
<variable name="AppLogPath" value="${LogHome}/BVS.log"/>
<variable name="LayoutFormat" value="${date:format=yyyy-MM-dd HH\:mm\:ss.fff} [${threadid}] ${level:uppercase=true} ${callsite} ${message} ${exception:format=ToString}" />
<variable name="EndProgram" value="|-------------------------------------------|${newline}${newline}${newline}${newline}${newline}${newline}"/>
<targets>
<target name="MyLogfile"
xsi:type="File"
fileName="${AppLogPath}"
archiveAboveSize="1024000"
header="${date:format=yyyy-MM-dd HH\:mm\:ss.fff}${newline}"
layout="${LayoutFormat}"
footer="${date:format=yyyy-MM-dd HH\:mm\:ss.fff}${EndProgram}"
archiveNumbering="DateAndSequence"
archiveDateFormat="yyyy-MM-dd"
maxArchiveFiles="500"
encoding="utf-8" />
</targets>
<rules>
<logger name="*" minlevel="Info" writeTo="MyLogfile" />
</rules>
</nlog>
Similar to #1713, the header is printed only at the start of a log file, even if my application shuts down and starts again.
I'd like headers to appear everytime my application starts, so I can tell in the log file which logs belong to each run of my application.
Thanks for reporting!
l think we should introduce 2 options
Has someone a better name proposal? ;)
Just to add info, I actually need the headerOnStart because if my application crashes (we can only hope) the footer is never printed.
If the footer was printed even if the app crashes I would not have requested this feature, not sure this is possible though.
What should happen on LoggingConfiguration-Reload (CloseTarget / InitializeTarget) ?
The header-logic is mostly for the CSV-layout. Why not manually write a log-message at startup like "Starting..." ?
Alternative solutions could be that you activated ArchiveOldFileOnStartup
An alternative approach could be to make a target-wrapper that injects an artificial LogEventInfo on first Log-Event (With an custom Layout to generate the message for the artifical LogEventInfo).
I'd like to have the option like "headerOnStart" too.
Regarding to
Why not manually write a log-message at startup like "Starting..." ?
this is not an elegant solution because such a logic produces the content as below:
----------------- Logging started on 2018-11-16 12:23:55.8735 ------------------
2018-11-16 12:23:55.8395 | Common | Info | Main form is opened |
----------------- Logging finished on 2018-11-16 12:24:10.4863 -----------------
2018-11-16 12:24:22.0540 | Common | Info | Main form is opened |
and is not what it should be.
I agree that this option "headerOnStart" could turn out to be very useful. Right now I'm writing the header manually because in our application we need to track when the app starts up.
Has this feature been introduced finally?
Nope. Feel free to send a PR! :)
@d3ns1ty Make sure to read https://github.com/NLog/NLog/issues/2119#issuecomment-302490558 before you start implementing a solution.
What should happen on LoggingConfiguration-Reload (CloseTarget / InitializeTarget) ?
I think in such a case one should leave an appropriate message in the log target, something as "The configuration have been reloaded", for example.
@zdens
I think the question is, will the headerOnStart printed on CloseTarget / InitializeTarget, and if not, how to remember that?
Especially when a new instance of the target is created on reload :)
I think the question is, will the headerOnStart printed on CloseTarget / InitializeTarget, and if not, how to remember that?
I think no, and remember it logfactory as static (name target - static hashset<string>). So if a new instance of a target is made (with the same name) if will be remembered. What do you think @snakefoot ?
As long it is done in a target wrapper and not polluting the file-target even more with random logic then it is fine with me
Would it be logic to have it available in other targets else than the file target? Database, event log maybe?
Anything where you need a starting and stopping event.
But remember a good library doesn't try to do everything. But should be good at its core stuff while being open and extensible. Careful with not adding everything but the kitchen sink to the NLog core
True, but I think this is a nice feature and suitable for NLog. If implemented as wrapper, it's modular :+1:
Are you going to implement this feature? @304NotModified
@mwagenfuehr Think you are very welcome to create a PullRequest and implement this feature.
@mwagenfuehr this isn't on the roadmap. PR is accepted :) (when having enough tests)
Most helpful comment
l think we should introduce 2 options
Has someone a better name proposal? ;)