If I create a console app for example with VS2019, then add NLOG and NLOG.SCHEMA NuGet packages, I configure NLog in app.config and it looks like this:
<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" throwConfigExceptions="true"
internalLogLevel="Off" internalLogToConsoleError="false" internalLogFile="c:\temp\nlog-internal.log">
...
My problem is if a new version of Nlog comes out and its updated via NuGet, it insists on adding a fairly empty section to my app.config. If I don't pick this up then the app will not run because there are two nlog sections.
Is there a way to prevent this? Apart from being more careful and checking after updates? I am thinking of putting the config in a separate file and see if that helps.
My problem is if a new version of Nlog comes out and its updated via NuGet,
This only happens when you update the NLog.Schema package. So you could skip updating that package. The schema package is not used for the behavior of NLog
Related
I've been struggling with handling a custom target.
When I type in my config file, type='MyTargetName', it doesn't recognize it, saying the xsd doesn't have a setting for it.
But, I've been reading and got the impression that xsd warnings don't effect the functionality.
Any tips on how you managed to get it working? Important to mention that my target works in run time, but not from the config file
Adding below code to my nlog.config worked for me
<extensions>
<add assembly="NLog.Targets.MyTargetName"/>
</extensions>
I am using NLog to write logs to my database,
I have created a file NLog.config which is writing logs to a text file as of now.
To write the logs to a database, I am following this tutorial.
However, the connectionstrings for diferrent environments can be only modified in Web.config. (I am using Azure App services). Is there any way I can refer the connection string from web.config in NLog.config.
TIA
If you not using ASP.NET Core (but "full" ASP.NET), you could use ${appsetting:name=..}
Install NLog.Extended with Nuget and use ${appsetting:name=..} in your config file.
e.g.
<target name="database"
type="Database"
connectionString="${appsetting:name=myConnectionString}" />
See also the ${appsetting} documentation
NB: It can only read <appSettings> and not <connectionStrings>
I'm trying to get nlog working with the Azure webapp Log Stream.
The logs do appear if I don't use nlog, and just use System.Diagnostics.Trace.WriteLine.
However, if I use the Trace type in my nlog.config, it doesn't show the trace logs ...
<?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 xsi:type="Trace" name="trace" layout="${message}" />
</targets>
<rules>
<logger name="*" minlevel="Trace" writeTo="trace" />
</rules>
</nlog>
I can't see anything that I'm doing differently from the accepted answer here ...
How to integrate NLog to write log to Azure Streaming log
Note that I cut down that nlog.config file to just show the trace - but I do normally also have a File target type - I've tried with and without this.
I've logged onto the deployed Azure website, and the nlog config file had been uploaded successfully. I'm deploying using the Github deployment.
I have the logging set in Azure to just use the file system logging, and I have that set to verbose.
Any ideas?
It turns out that when Visual Studio enabled Application Insights (a recent thing I added to the project), it had inserted an nlog config section into my web.config. This had then meant that my nlog.config file wasn't being used at all. I've fixed it by removing that nlog config section from my web.config, and copying the Application Insights target into my nlog.config file instead. The 'Trace' target type now works as expected and is appearing in the Azure Streaming Logs.
The NLog-Trace-Target only performs Trace.WriteLine for Debug-Level Log-Events.
Maybe try the custom MyTraceTarget shown here:
https://github.com/NLog/NLog/issues/1968
Update NLog ver. 4.5 adds the new setting rawWrite for the NLog Trace-target so it always performs WriteLine independent of LogLevel. See also https://github.com/NLog/NLog/wiki/Trace-target
If I publish to Azure Cloud Service using the Cloud Project and follow the publish wizard from it works fine but only if I delete the last Pubxml file (stored in the profile folder) first.
If I try and publish when a Pubxml file already exists it will hang trying to navigate between wizard steps.
Using SDK V2.9.6, although had the same issue on previous versions.
I have multiple subscriptions, and the issue seems to be whilst the Pubxml does store the subscription, it is ignored and the default (first one in the list alphabetically) is used instead.
So if I run a publish where there was a previous Pubxml, it jumps to the Diagnostics page. I click next for the summary and the issue areas are highlighted with a red error indicator (it has the wrong subscription selected by default, and hence it cannot find the correct cloud service). However I cannot click back as it just hangs.
I'm using SDK V2.9.6, and didn't see this problem. Actually, my pubxml files have subscription information included.
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<AzureCredentials>{"ServiceManagementEndpoint":"https:\/\/management.core.windows.net\/","ResourceManagementEndpoint":"https:\/\/management.azure.com\/","SubscriptionId":"my-subscription-id"}</AzureCredentials>
...
</PropertyGroup>
</Project>
Which version of Azure SDK is your pubxml files generated from?
I'm looking for best practices to integrate log4net to SharePoint for web request, feature activation and all timer stuff.
I have several subprojects in my farm, and I would like to have only one Log4Net.config file.
[Edit]
Not only I need to configure log4net for the web application, which is easy to do (I use global.asax, and a log4net.config file, so I can modify log settings withtout reloading the webapp), but I also need to log asynchronous events:
Event Handler (like ItemAdded)
Timer Jobs
...
I implemented this recently and came up with a solution that worked for me.
Deploy your log4net config file to the 12 hive and the log4net dll into the GAC using a globally scoped solution. Then in your application code explicitly initialize log4net from the location of your global file. This allows you to log feature receiver, timer jobs and web application code.
[assembly: log4net.Config.XmlConfigurator(ConfigFile =
#"C:\Program Files\Common Files\Microsoft Shared\" +
#"Web Server Extensions\12\CONFIG\log4net.config", Watch = true)]
see here http://www.codeproject.com/KB/sharepoint/SharepointLog4Net.aspx
Firstly, you will need to modify the web.config where your SharePoint virtual directory resides. This is because you'll need to add SafeControl entries to trust the log4net assembly. You can update the web.config programmatically using the SPWebConfigModification class in a feature receiver. As you have to modify web.config anyway, you may want to consider including your log4net config inside and not set up an external log4net config.
However, if you'd still like to do this, it may work if you add the following to the web.config file:
<configuration ...>
...
<configSections>
<section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler,log4net" />
</configSections>
<log4net configSource="log4Net.config">
...
</configuration>
The log4net.config file should then be able to live alongside your web.config. As Nat says, you could deploy this file as a solution package.
Assuming you are attempting to run a minimal trust, you will need to update your Code Access Security file to include the log4net assemblies as well. All of your custom SharePoint code should then automatically use your log4net configuration.
You could release the config file as part of the solution package(s) to the 12 hive (use STSDev) to create any packages). This would give you a set location for the config and any changes to it can be released in a controlled manner (i.e. no need for manual editm, just roll back and re-install the solution).
I developed a log4net feature and packaged it in a wsp file. The feature receiver adds an httpmodule to the the web.config and the httpmodule loads the log4net.config from the layouts direcory when the application start event is raised in the http module.