nLog 2.1 does not working on Windows Server 2012

[Tamás Stocker]

I have a working ASP.NET MVC 4 C# app, which is nicely logging on my developer (Windows 7) machine and in the test environment (Windows Server 2008 R2).
But, this same app, doesn't log anything in production environment, on a Windows Server 2012. The web.config is the same as on 2008 R2.

I've already read through the solutions on Stackoverflow, but neither working.

Any idea?

Thanks in advance.
Bye

[Kim Christensen]

Hi Tamás,

Could you try to enable the internal log, see https://github.com/NLog/NLog/wiki/Logging-troubleshooting, and post it here?

Unfortunately I'm on vacation the next 2 weeks, so I may not be quick to answer this thread

2014/1/23 Tamás Stocker <tamas.st...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "NLog-Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nlog-users+...@googlegroups.com.
To post to this group, send email to nlog-...@googlegroups.com.
Visit this group at http://groups.google.com/group/nlog-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Tamás Stocker]

Hi Kim,

I've already enabled the internal logging. Neither on the production (Windows Server 2008 R2, 2012), nor on the development machines internal log haven't been created. Here is my Web.Config portion:

  <nlog autoReload="true" throwExceptions="true" internalLogFile="${basedir}/Logs/internal_log.txt" internalLogLevel="Trace">
    <variable name="logDirectory" value="${basedir}/Logs" />
    <targets async="true">
      <target name="traceGroup" type="SplitGroup">
        <target name="VS_debug_window" type="Debugger" layout="${longdate}|${aspnet-user-identity}|${logger:shortName=true}.${callsite:className=false:fileName=false:includeSourcePath=false:methodName=true}()|${message}" />
        <target name="traceFile" type="File" fileName="${logDirectory}/trace_${shortdate}.txt" keepFileOpen="false" layout="${longdate}|${aspnet-user-identity}|${logger:shortName=true}.${callsite:className=false:fileName=false:includeSourcePath=false:methodName=true}()|${message}${onexception:${newline}${exception:format=ToString:maxInnerExceptionLevel=10:innerFormat=ToString}}" />
      </target>
      <target name="logFile" type="File" fileName="${logDirectory}/log_${shortdate}.txt" keepFileOpen="false" layout="${longdate}|${level:uppercase=true}|${aspnet-user-identity}|${logger:shortName=true}.${callsite:className=false:fileName=false:includeSourcePath=false:methodName=true}|${message}${onexception:${newline}${exception:format=ToString:maxInnerExceptionLevel=10:innerFormat=ToString}}" />
    </targets>
    <rules>
      <logger name="*" maxlevel="Trace" writeTo="traceGroup" />
      <logger name="*" minlevel="Debug" writeTo="logFile" />
    </rules>
  </nlog>

As far as I see this must be enough (no different Tracing statements needed for internal logging, and so many common Trace are there in the code, which ones working on 2008 R2). But still nothing happens on 2012.

[Kim Christensen]

Could you post a sample project with the issue?

[Jonny Bergdahl]

Check the permissions for the folder you log to. By default IIS runs under the "IIS AppPool\DefaultAppPool" user, which has very little permissions in the system.

Regards;
/jb

[Tamás Stocker]

Thank you Jonny! Your comment helps.

Although the Logs sub-directory had not been existed previously (this is my logging target), when I created it (on Windows Server 2012 machine) and give "Modify" (and automatically additions) permission to the ".NET v4.5" group (I didn't found "IIS AppPool\DefaultAppPool" user what you mentioned, this machine is in a Domain), nLog magically started to log into this directory.

So for others who read this, the solution consists on Windows Server 2012:
- Create the logging target directory if that does not exist. On Windows Server 2008 R2 and Windows 7, that had been enough to write the target directory into the nLog config part (in my case in web.config). On Windows Server 2012 it is not enough or a too strict domain rule did this.
- Give "Modify" (and Write) permissions to ".NET v4.5" group or what framework your application is targeted. If you find a more secure user or group which is working, apply the permissions to only that.

Regards,
T