I have a solution I built using .NET 4.7. This solution has two projects:
A class library (.NET 4.7.2)
A Unit Test Project (.NET Framework)
I'm trying to migrate this solution to use .NET Standard | Core.
I have successfully transferred the class library to a .NET Standard 2.0 project. I have also transferred the Unit Test Project to a .NET Core 2.0 mstest project. Everything compiles. I can run my tests as expected. However, no logs are getting written via NLog.
In my .NET 4.7 version of the solution, when I ran the unit tests, an actual log file was written via NLog. However, in the new .NET Standard | Core implementation, this log file is not getting written. I have the following two files in my mstest project:
App.config
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
</configuration>
nlog.config
<?xml version="1.0" encoding="utf-8" ?>
<!-- XSD manual extracted from package NLog.Schema: https://www.nuget.org/packages/NLog.Schema-->
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
xsi:schemaLocation="NLog NLog.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
autoReload="true"
internalLogFile="c:\temp\console-example-internal.log"
internalLogLevel="Info" >
<targets>
<target name="myLogs" xsi:type="File" deleteOldFileOnStartup="true" fileName="${basedir}/logs/MyLogs.json" createDirs="true" keepFileOpen="true" encoding="utf-8" layout="${message}" />
<target name="traceLogs" xsi:type="File" deleteOldFileOnStartup="true" fileName="${basedir}/logs/trace.log" createDirs="true" keepFileOpen="true" encoding="utf-8" layout="[${longdate}] ${message}${exception:format=ToString}"></target>
</targets>
<rules>
<logger name="MyLogger" minlevel="Info" writeTo="myLogs" />
<logger name="TraceLogger" minlevel="Trace" writeTo="traceLogs" />
</rules>
</nlog>
In my mstest project, I've also added references to:
Microsoft.Extensions.DependencyInjection
NLog
NLog.Extensions.Logging
I followed the steps outlined here. Except, I didn't do anything beyond step 2. Do I need that stuff for a mstest project? If so, where? It seems like a lot of additional stuff for something that was already working.
When running unit tests, it's hard to find the nlog.config as implementations will move the DLLs (and most of the time not the nlog.config) to temporary folders.
It's recommend to configure NLog from code in an unit test project. (how-to here)
Another option is to load the NLog config file manually. You need to provide the path to nlog.config to the XmlLoggingConfiguration contructor:
LogManager.Configuration = new XmlLoggingConfiguration(pathToNLogConfig);
Off topic but related:
In the unit test it's recommend to write the eventlogs not to a file, but in memory, e.g. the Memory target. It makes the unit test more robust.
Related
I am using NLog 4.5.11 in one Visual Studio 2017 solution. It has the nlog.config in the start up project, but the actual logging required is from another project, where NLog is referenced (but no nlog.config exists). Running this solution works fine, the NLog logs are being produced where I expect.
The second VS solution uses (references) both the start up project and the one with the logging. One note on this project is that it is an Excel Add-on. When I run (debug from VS) this second solution, I do NOT get the NLog logging that should have been triggered via the referenced projects' code and NLog logging. I do not get any errors, exceptions, or error files etc.
I have tried also installing the NuGet packages for NLog to the second solution. I also tried adding a copy of the nlog.config to it. I have looked in the build directory and the NLog dlls and config file are being copied there. I have also tried enabling the throwExceptions="true" and internalLogLevel="Trace".
I have been looking on SO and elsewhere, but I cannot find a solution or even how to debug it. All that ever happens is simply no output, which is really frustrating.
NLog.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"
xsi:schemaLocation="http://www.nlog-project.org/schemas/NLog.xsd NLog.xsd"
autoReload="true"
throwExceptions="true"
internalLogLevel="Trace" internalLogFile="c:\temp\nlog-internal.log">
<variable name="appName" value="FSIS" />
<variable name="logDir" value="c:\temp\Rbnz.Fsis.Logging" />
<variable name="logDirArchive" value="c:\temp\Archive\Rbnz.Fsis.Logging" />
<targets async="true">
<target xsi:type="File"
name="default"
layout="${longdate} - ${level:uppercase=true}: ${message}${onexception:${newline}EXCEPTION\: ${exception:format=ToString}}"
fileName="${logDir}\${shortdate}.log"
keepFileOpen="false"
archiveFileName="${logDirArchive}\${shortdate}.{##}.log"
archiveNumbering="Sequence"
archiveEvery="Day"
maxArchiveFiles="30"
/>
</targets>
<rules>
<logger name="*" writeTo="default" minlevel="Debug" />
</rules>
</nlog>
Usage inside the code of the referenced project:
private static NLog.Logger logger = NLog.LogManager.GetCurrentClassLogger();
and later on, inside a method:
logger.Info("Start: CompileSeries()");
logger.Info("Done: CompileSeries()");
I expected that if NLog logging works for a project, then including that project as a reference in another project (in another solution), would trigger the same logging. Obviously I'm incorrect in this assumption.
Based on what you wrote, you have a First Solution that has two projects--a startup project that configures a logger object. That solution has a second project that references the startup project's logger object. Fine.
Now you have a Second Solution. In this solution, you simply reference the First Solution's startup project assembly and the First Solution's second project. Your Second Solution has its own project that's trying to access the logger exposed by the First Solution's referenced projects.
This issue is that your First Solution actually executes its startup project. Your Second Solution does not execute it--it simply references it. Therefore, your logger object isn't getting properly initialized by NLog.
The solution (generically) is to ensure that your logger object is initialized in your Second Solution just as it's initialized in your First Solution. If you want more specific guidance, show specifics as to how your First Solution's startup project initializes the logger object and I should be able to help you replicate that logic in the Second Solution.
Your conclusion that you cannot log from another solution is incorrect. It's all about proper object initialization.
I hope this helps.
As the title says, I want my Logger to not be ignored when running unit tests using XUnit. I want it still to log. If this is possible, how can it be done?
Here is 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">
<targets>
<target name="log"
xsi:type="File"
fileName="${basedir}/logs/log.${longdate:cached=true}.log"
layout="${message}"
archiveFileName="${basedir}/logs/archives/log.${shortdate}.{#}.log"
archiveAboveSize="5242880"
archiveEvery="Day"
archiveNumbering = "Rolling"
maxArchiveFiles="20"
/>
<target name="logconsole" xsi:type="Console" />
</targets>
<rules>
<logger name="*" minlevel="Info" writeTo="logconsole" />
<logger name="*" minlevel="trace" writeTo="log" />
</rules>
</nlog>
I just have a backend and no frontend, so when I run the tests I want to see that everything logs :)
You could use NLog in unit tests. Unfortunately it's difficult for NLog to find the path to the nlog.config as unit test frameworks move the binaries between folders - and not the nlog.config.
Also it's different in different environments/frameworks (NUnit, xUnit, MSTest, .NET full, .NET Core)
You could do:
Write the configuration in C#. See Docs
Or tell NLog the path to the config:
LogManager.Configuration = new XmlLoggingConfiguration("pathToNLogConfig/nlog.config");
Also recommend for logging in unit tests, write to the memory target instead of file/database etc. You could also retrieve in code the logged events. See memory target docs
In starting to create a custom StyleCop rule I have followed the instructions on the Visual StyleCop Github.
• I've created a class, MyStyleCopRules.cs:
[SourceAnalyzer(typeof(CsParser))]
public class MyStyleCopRules : SourceAnalyzer
{
public override void AnalyzeDocument(CodeDocument document)
{
...
• Added an XML document, with the build action set to EmbeddedResource, called MyStyleCopRules.xml:
<?xml version="1.0" encoding="utf-8" ?>
<SourceAnalyzer Name="My StyleCop Rules">
<Rules>
<Rule Name="Fully Qualified Using Statements" CheckId="IS0001">
<Context>Using statements must be fully qualifed.</Context>
<Description>Fires when using statements are not fully qualifed.</Description>
</Rule>
</Rules>
</SourceAnalyzer>
Other possibly pertinent facts:
This library is building, in release, at Framework 3.5.
I have dropped a release build of this library in the same directory as StyleCop
I use StyleCop.MSBuild (version 4.7.50) for the StyleCop integration, so I am copying it to \packages\StyleCop.MSBuild.{version}\tools.
The version of StyleCop referenced within the library, is the same as the one I am copying it next to. (I have checked the versions using ILSpy.)
I am using Visual Studio 2015, but I am not using Analyzers
I don't see the rules when I open the Settings.StyleCop file, nor do I see any indication that they run with Visual Studio.
What have I missed?
The Fully Qualified Using Statements needs to have no spaces in it.
Namely:
<?xml version="1.0" encoding="utf-8" ?>
<SourceAnalyzer Name="My StyleCop Rules">
<Rules>
<Rule Name="FullyQualifiedUsingStatements" CheckId="IS0001">
<Context>Using statements must be fully qualifed.</Context>
<Description>Fires when using statements are not fully qualifed.</Description>
</Rule>
</Rules>
</SourceAnalyzer>
My NLog targets is like this:
<targets>
<target xsi:type="Console" name="console"
layout="${longdate}|${level}|${message}" />
<target xsi:type="File" name="ErrorLog" fileName="${basedir}/error.txt"
layout="${longdate}
Trace: ${stacktrace}
${message}" />
<target xsi:type="File" name="AccessLog" fileName="${basedir}/access.txt"
layout="${shortdate} | ${message}" />
</targets>
But this causes problems if the user isn't an admin on their machine, because they will not have write access to "Program Files". How can I get something like %AppData% to NLog instead of BaseDir?
You're looking for the NLog special folders.
Example:
...fileName="${specialfolder:folder=ApplicationData}/Program/file.txt"...
Oren's answer should be the right answer. However, for the life of me I couldn't get it to work with my .NET 4.0 website using nLog 2.0.0.0. I ended up using simply
fileName="${basedir}app_data\logs\${shortdate}.log"
${specialfolder:ApplicationData} also works
The previous answers helped solve the problem I was having, but a couple of years later and the solution is now somewhat different under v4.3. The directory and filename are combined with the path.
#theGecko's link is still current for the syntax, but the page is deficient of an example:
https://github.com/nlog/NLog/wiki/Special-Folder-Layout-Renderer
The following example would write the file myLog.log to the current users application data roaming directory C:\USers\current.user\AppData\Roaming\My\Path\Somewhere:
fileName="${specialfolder:dir=My/Path/Somewhere/:file=myFile.log:folder=ApplicationData}"
For logging to the project directory:
While the previous answers work for the original question, searching for how to log to the project APP_DATA directory leads to this question. And while bkaid's answer works for ASP.NET and for using the APP_DATA folder specifically, for .NET Core and .NET 5 the solution is a bit different, because that motif has been abandoned in favor of defining a wwwroot folder for only those things which should be served, and the remainder being private. The answer for .NET Core/5, then, is to write to the solution root directory:
First, ensure the NLog.Web.AspNetCore assembly is added to nlog.config:
<extensions>
<add assembly="NLog.Web.AspNetCore"/>
</extensions>
Then use one of the layout renderers provided by that extension, in this case ${aspnet-appbasepath} which references the solution root directory:
<targets>
<target name="file"
type="File"
xsi:type="File"
fileName="${aspnet-appbasepath}/log/${shortdate}.log"
layout="${longdate}|${event-properties:item=EventId_Id:whenEmpty=0}"/>
</targets>
This will write the file to <solution folder>/log/2021-07-01.log, which will never be served by the public-facing website. Other layout renderers provided by this assembly are listed on the NLog website.
I am using NLog to log the exceptions in my asp.net mvc (C#) application.
NLog is not working in release mode. The same is working when running in debug mode.
What may be the problem? Is there any fix for this?
I was having the same problem as you:
ASP.NET MVC 3
.NET 4
IIS 7
Release Mode
I tried changing directories, and changing permissions to no avail. I even tried enabling the internal logging but even that didn't work! No failures, no exceptions, nothing!
After doing some more investigating, I found the solution. For some reason, NLog wasn't loading the config file AT ALL. I realized this after I programmatically enabled the internal logging. The internal logging reported this:
2012-02-13 11:34:40.3181 Debug Targets for MyMvcController by level:
2012-02-13 11:34:40.3181 Debug Trace =>
2012-02-13 11:34:40.3181 Debug Debug =>
2012-02-13 11:34:40.3181 Debug Info =>
2012-02-13 11:34:40.3181 Debug Warn =>
2012-02-13 11:34:40.3181 Debug Error =>
2012-02-13 11:34:40.3181 Debug Fatal =>
This was basically saying that there were no targets defined for any of the log levels! Definitely not correct!
My NLog configuration file was as simple as it could be (and it was set to Copy to Output Directory):
<configuration>
<configSections>
<section name="nlog" type="NLog.Config.ConfigSectionHandler, NLog"/>
</configSections>
<!-- Other XML Sections -->
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<targets>
<target name="file" xsi:type="File" fileName="${basedir}/MyApplication.log" />
</targets>
<rules>
<logger name="*" minlevel="Trace" writeTo="file" />
</rules>
</nlog>
</configuration>
I'm still not sure exactly why this was happening, but moving the NLog configuration into the web.config directly resolved the problem.
See also: https://github.com/nlog/NLog/wiki/Configuration-file#configuration-file-format
set up environment variables:NLOG_INTERNAL_LOG_LEVEL and NLOG_INTERNAL_LOG_FILE, rerun your release build then check the log file see what's wrong
For anyone, who is not sure about 'why nlog is not working in prod environment':
Go to Nlog.config file
SET throwExceptions="true" in nlog tag
and start debugging with proper errors.
Good luck.
I think you should provide to your publish directory IIS_IUSRS to Write Permission.
Transfer nlog config to config file of your application (web.config for example), and try again.
Make sure your target file saves within a "/logs/" folder. See below
<target xsi:type="File" name="f" fileName="${basedir}/logs/${shortdate}.log"
layout="${longdate} ${uppercase:${level}} ${message}" />
I tried to log into "root/log.log" and was not working, then tried "root/logs/log.log" and worked
Below full config file.
<?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"
xsi:schemaLocation="http://www.nlog-project.org/schemas/NLog.xsd NLog.xsd"
autoReload="true"
throwExceptions="false"
internalLogLevel="Off" internalLogFile="c:\temp\nlog-internal.log" >
<!-- optional, add some variabeles
https://github.com/nlog/NLog/wiki/Configuration-file#variables
-->
<variable name="myvar" value="myvalue"/>
<!--
See https://github.com/nlog/nlog/wiki/Configuration-file
for information on customizing logging rules and outputs.
-->
<targets>
<!--
add your targets here
See https://github.com/nlog/NLog/wiki/Targets for possible targets.
See https://github.com/nlog/NLog/wiki/Layout-Renderers for the possible layout renderers.
-->
<!--
Writing events to the a file with the date in the filename. -->
<target xsi:type="File" name="f" fileName="${basedir}/logs/${shortdate}.log"
layout="${longdate} ${uppercase:${level}} ${message}" />
</targets>
<rules>
<!-- add your logging rules here -->
<!--
Write all events with minimal level of Debug (So Debug, Info, Warn, Error and Fatal, but not Trace) to "f"-->
<logger name="*" minlevel="Debug" writeTo="f" />
</rules>
</nlog>
You can activate the NLog InternalLogger from code, so you can rule out the issue with correct deployment of NLog.config:
// enable internal logging to the console
NLog.Common.InternalLogger.LogToConsole = true;
// enable internal logging to a file
NLog.Common.InternalLogger.LogFile = "c:\\nlog-internal.txt"; // On Linux one can use "/home/nlog-internal.txt"
// set internal log level
NLog.Common.InternalLogger.LogLevel = LogLevel.Debug;
// Perform test output, ensure first NLog Logger is created after InternalLogger is enabled.
NLog.LogManager.GetLogger("Test").Info("Hello World");
See also: https://github.com/NLog/NLog/wiki/Internal-Logging
See also: https://github.com/NLog/NLog/wiki/Logging-troubleshooting
Another thing worth checking is the write permission of your log directory and/or files.
Permission error, or any other error, will show up in the internal log if enabled. This is how I set up my NLog.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"
xsi:schemaLocation="http://www.nlog-project.org/schemas/NLog.xsd NLog.xsd"
autoReload="true"
<!-- setting to True will break your application so be careful -->
throwExceptions="false"
<!-- change level to your preference -->
internalLogLevel="Error" internalLogFile="c:\your-path\nlog-internal.log">
<!-- your NLog settings -->
<!-- ... -->
</nlog>
Assuming you've configured NLog in the right way, like the other answers suggest, Try one of these
Write Permission for your Server
If you are using IIS, give WRITE permission for user IIS_IUSRS for your log folder.
Constructor
public LoggerService() {
_logger = NLogBuilder.ConfigureNLog("nlog.config").GetCurrentClassLogger();
}
The path for nlog.config could be different for you. Mine was on the same folder