We have an asp.net application that logs errors and warnings to xml files using log4net.
We have tried quite a few log4net viewers but didn't find any decent ones.
The latest one we have tried is log4net dashboard which is pretty good but doesn't do exactly what we need.
Our logs are saved in C:\MyApp\Logs[year][month]\log[date].xml
Is there any decent web based viewer that can allow us to view all the logs under C:\MyApp\Logs\
The viewer doesn't need to have a free license for use.
I see a post on their blog for this issue and how to work around it while a new build is dropped.
http://blog.reflectsoftware.com/2013/04/17/directorynotfoundexception/
I can confirm that creating this directory manually resolves the exception that is thrown.
I've used l4ndash in the past and it is a good tool.
Have you tried changing this in the web.config?
This should load all files in that folder.
<datasource name="XML Text file" Description="XML Text file (output from FilAppender or RollingFileAppender)">
<provider type="L4NDashXmlTextFileProvider.XmlTextFileProvider" assembly="L4NDashXmlTextFileProvider, Version=2.4, Culture=neutral"/>
<predefinedsearchfilter value="Filters\DefaultSearchFilters.xml"/>
<providersettings>
<filename value="C:\MyApp\Logs\*.*" />
<SleepOnRename value="100"/>
</providersettings>
Related
We have application insights running in our application (on premise and hosted in azure) and we are sending telemetry without issues, different resources, regular data, pageViews, exceptions, traces etc, recently I was asked to increase the telemetry data by adding Windows Event logs (from event viewer), but, to be honest, I am quite new with azure or application insights and all the documentation I find it a bit confusing, since all I find talks about azure monitor, log analytics workspaces configuration, but nothing clear enough (at least to me) that points me to get this data logged into application insights resources specifically. Is this possible to achieve? Something like adding a nuget package and configure applicationInsights.config?
Update... I've followed your suggestions, and added the nuget package for EtwCollectorTelemetryModule, and modified the applicationInsights.config file.
This is how it looks now:
<Add Type="Microsoft.ApplicationInsights.EtwCollector.EtwCollectorTelemetryModule, Microsoft.ApplicationInsights.EtwCollector"> <Sources <Add ProviderName="Microsoft-Windows-Eventlog" Level="Warning" /> </Sources>
But, I'm still not able to see any kind of logs in the traces table (if i understand correctly, logs will be sent to that table.) Do I need to initialize this module in order to start tracing these logs?
Or am I doing something wrong?
I agree with #Peter Bons here. When you need to add Windows Event logs to azure application insights, you need to add ETW module in the config file.
And pls note here, the EtwCollectorTelemetryModule is an asp.net module so that it suitable for asp.net application.
You can refer to this tutorial to modify the configuration if your program written in asp.net. Pls note, Add Application Insights Telemetry mentioned in the doc is the operation 'right click the project and click Configure Application Insights'
I've been attempting to fix a problem I have with Test Explorer not showing tests when I'm in a different configuration environment. I make local environment changes by updating my app.config.
I have already tried a few steps found here and in other sites including cleaning my project, updating to the latest xUnit test runner, etc.
I am sure the reason is code/project based and not the Visual Studio environment itself. What I would like to know is whether or not there is a log file I can look at that would help me to determine why my tests are not showing. Or, is there another good method to troubleshoot errors with tests not showing up in Test Explorer?
There is a MSDN Blog post about this.
Essentially, you need to:
Go to folder %VSInstallDir%\Common7\IDE\CommonExtensions\Microsoft\TestWindow
Find the config file for the process you want to debug (e.g. vstest.console.exe.config, vstest.discoveryengine.exe.config, etc)
Alter the config file system.diagnostics node to include:
<system.diagnostics>
<switches>
<add name="TpTraceLevel" value="4" />
</switches>
</system.diagnostics>
Close VisualStudio, open it again, and discover/run tests from TestExplorer Window
Look for logs under %temp%[processname].TpTrace.log (e.g. vstest.console.tptrace.log)
I have been assigned a project with a lot of poorly written code that is based around SharePoint.
It consists of about 15 subprojects, some of them being windows services, some web services, some web applications running inside of SharePoint, some being webparts and even console applications. They all run on the same server and call each other.
There are already many issues in production but they are hard to trace down.
The original developer must have been a fan of either Salinger or Pokémon series judging by his tireless effort to catch all exceptions. Unfortunately, none of them get reported or logged, ever.
My current task is to introduce logging into the whole project so I could find now-invisible exceptions, follow tangled recurring calls and have some stack traces at least. I decided to go with NLog, seeing it's active and cool, as opposed to log4net which is perfectly fine but somewhat not as fancy to my taste.
Because the components are tightly coupled, I want to centralize logging in one file so related errors don't get scattered across the hard drive. Therefore, I am looking to have two or three different log files with five or more projects writing to each of them more or less simultaneously.
What is the best way to configure NLog to centralize logging? Should I have a config file for each project, or should related projects share them? Where should I put config file to log from SharePoint webparts? Am I going to face any permission issues?
I'm using SharePoint 2007.
The easiest way to centralize is probably to simply log to a database, one benefit being that multiple applications and write to the database easier than to the same log file. For each application, configure NLog to log to the Database target, using the same Database target configuration parameters for each. Your NLog.config file might look something like this:
<?xml version="1.0" encoding="utf-8" ?>
<!--
This file needs to be put in the application directory. Make sure to set
'Copy to Output Directory' option in Visual Studio.
-->
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
autoReload="true"
internalLogLevel="Debug"
internalLogFile="nlog_log.log">
<targets async="true">
<target name="sqlexpress" xsi:type="Database">
<connectionString>
Data Source=.\SQLEXPRESS;Initial Catalog=LoggingDB;Integrated Security=True;
</connectionString>
<commandText>
insert into LogTable(DateTime,Logger,LogLevel,Message,ProcessId,ManagedThreadId) values (#DateTime,#Logger,#LogLevel,#Message,#ProcessId,#ManagedThreadId);
</commandText>
<parameter name="#DateTime" layout="${date:format=yyyy\-MM\-dd HH\:mm\:ss.fff}"/>
<parameter name="#Logger" layout="${logger}"/>
<parameter name="#LogLevel" layout="${level}"/>
<parameter name="#Message" layout="${message}"/>
</target>
</target>
</targets>
<rules>
<logger name="*" minlevel="Trace" writeTo="sqlexpress" />
</rules>
</nlog>
You could certainly log to files in addition to (or instead of) logging to a database.
I am not familiar with doing this from SharePoint, so I can't comment on any configuration or permission issues that you might run into there.
Here is a link I found where there is a discussion of getting NLog to work in a SharePoint environment:
http://nlog-forum.1685105.n2.nabble.com/Is-anyone-using-NLog-with-SharePoint-td2171451.html
That link appears to put you at the top of the NLog forum instead of the specific post. Search for this text in the forum "Is anyone using NLog with SharePoint" and you should find the right post.
Good luck!
You could also just leverage the existing logging infrastructure in SharePoint and write to the ULS logs. This way your log information can be viewed in a complete context using the ULS log viewer. For SharePoint 2007 see this blog how to write to the ULS log:
SharePoint Trace Logs and the Unified Logging Service (ULS)
With SharePoint 2010 it has become even easier with improvements to the SPDiagnosticsService class where you can use the new WriteTrace method.
Personally I log Exceptions to the Event Logger. And I use NLog for logging details, debug information or tracing.
Since NLog can be easily switched on and off I only activate it when I'm debugging or when I need to inspect an exception in production. I never was a big fan of the default tracing functionality in .NET.
I prefer simple plain text log files. Although logging to a database works great if you don't have too many "log lines" implemented in your code.
I feel like we are working on the same project! Multiple projects consisting of web projects, core dll projects, console apps, services, etc. Unfortunately I'm not working in sharepoint like you are, but I can describe how I am trying to centralize our logging.
We have 1 core .Net framework project.This is where I placed our wrapper class of the log. This project also holds the nlog dlls and the nlog config file. In this core project file you can add this which automatically moves the config when you build projects with a dependency on this core project.
<None Include="Logging\NLog.config">
<link>NLog.config</link>
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
</None>
We found that some web projects that don't compile a dll don't automatically pull in the config file, so we will leave that up to the build process. This helps centralize our logging so you only have to manage a single config across them all.
In addition remember when you create a logger per class, the log name should have the namespace in it, so you can make specific targets that filter based off namespace if you want different settings for particular projects.
As for centralizing where the logs end up, we chose to use a file target and specify the full path. This is because on our servers the applications run off a C:\ but we have larger D:\ which can store the logs. In our production servers, we also have multiple servers, so we are using splunk to aggregate all of our logs.
If splunk is out of the question and you are on a distributed system, a database sounds like a good idea as suggested above. If you don't want to stand up an sql instance, there are target wrappers for mongo db as well.
Hopefully helpful, I'm curious if anyone has suggestions or opinions on how I'm doing it as well!
I created a code behind file for a custom master page in visual studio. I hooked everything up manually; safe control and custom cas policy. Everything works great!
I then wanted to put this into a sharepoint solution using WSPBuilder for better deployment. I created WSP solution, added my class file and changed the output directory to the bin folder. I then built the solution and deployed it, making sure to change the page directives on the master page to reflect the new assembly name.
Now when I go to view the sharepoint site I get an error stating Security Exception error stating
‘Exception Details: System.Security.SecurityException: That assembly does not allow partially trusted callers.’
This has me stumped as it works as a visual studio class file deployed to the bin directory of the website.
However when I put this into a sharepoint solution it breaks! I tried adding
‘[assembly: System.Security.AllowPartiallyTrustedCallers]’
to the AssemblyInfo.cs but this hasn’t helped.
Anyone else experinced this or have any advice?
EDIT: I should also mention that the code behind is trying to access a sharepoint list.
Don´t you still have to include the SafeControls entry in order for it to work, like:
<SafeControl Assembly="[FullAssembly Name]"
Namespace="[YourMasterPageNamespace]"
TypeName="*"
Safe="True" />
or in WSPBuilder config:
<add key="BuildSafeControls" value="True" />
Never seen this.. but I suspect not many people have created codebehinds to the master pages in SharePoint (Microsoft doesn't too!).
I don't know what you are trying to build but I'd probably implement it using a server control that is included on the master page.
AllowPartiallyTrustedCallers has always fixed it for my server controls.
What is the trust in your web.config file set to? Try Full.
Are you calling a third party assembly?
I ran into a situation recently that I was using a third party assembly and it did not have AllowPartiallyTrustedCallers in its code. When I tried to use the assebmly, it would fail.
Are you sure that the assembly has been deployed to bin and no to GAC by accident? If there are two assemblies the one in GAC takes precedence.
You might try checking that you are using the fully qualified five part name including the correct public key token and namespace for your assemblies.
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.