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>
Related
I have an issue trying to publish my customization project in the Customization Project Editor. The compilation panel remains completely in blank and I don't get any information.
See the screenshot below:
Can you help me with this?
You can check root cause and solution in this article:
https://community.acumatica.com/articles/382
This issue is caused by .NET version 4.8.4250. Workaround is to add the following key to appSettings section of your web.config.
<add key="aspnet:DisableAppPathModifier" value="false" />
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
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)
Windows vista 32 bit - C# - .NET 4 - sqlite - IIS 7
I'm building a small project that contains is a custom HTTP handler where an user can request a XML file and the project will generate the file and send it to the user. It should be flexible enough to send something else too like e.g. json.
Everything was going well until I had to deploy the handler. I've created a library (dll) file which contains the logic for serving of the requested information. I've open IIS manager and I've created a virtual directory to the debug bin file (later on i made it an application. it did not make a difference).
I've followed countless examples and tutorials like these ones:
I started with this one: http://support.microsoft.com/kb/308001
http://msdn.microsoft.com/en-us/library/bb515343.aspx
msdn.microsoft.com/en-us/library/46c5ddfy.aspx
But with no luck. As you could have read I'm not using any asp.net website even though I do have a web.config that I've added to the bin folder and it looks like this:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.webServer>
<httpErrors errorMode="Detailed" />
<asp scriptErrorSentToBrowser="true" />
<directoryBrowse enabled="false" />
<handlers accessPolicy="Read, Script, Execute">
<add name="LigoManagedHandler" path="*" verb="*" type="Ligo.Service, Ligo" resourceType="Unspecified" preCondition="integratedMode" />
</handlers>
</system.webServer>
</configuration>
When I try to run handler in the browser get the following error:
Could not load file or assembly 'Ligo' or one of its dependencies. The system cannot find the file specified.
Exception Details: System.IO.FileNotFoundException: Could not load file or assembly 'Ligo' or one of its dependencies. The system cannot find the file specified.
I have tried so many possible combination in IIS manager to get it working ('httphandlers', 'classic mode' and so on ...) but i'm truly stuck. The information I've found on the internet is not helping much.
What am I doing wrong or missing to make it work?
Something in this rant triggered an idea, an I stumbled on the answer.
The line in all those tutorials that say put type="ClassName, AssemblyName" into the Handlers section in Web.Config are plain WRONG.
All I did was change this to type="AssemblyName.ClassName" and everything started working, in both a Web Site Project and a Web Application Project that I had created.
I'm running IIS 7.5 in integrated mode so YMMV.
Craig
I figure it out. I had to make a asp.net website project and add my dll as reference to this project.
I read this thread that provided this information which is not clear on the internet.
http://forums.asp.net/t/1088861.aspx/1?What+causes+the+quot+Could+not+load+type+quot+problem+
It should state that it is not possible to make the httphandler without a aspnet website project. or am i mistaken? the example on the internet are incorrect! or provide too little information.
I know, this is an old thread. However, I've been looking for an answer for a few days without finding a clear one. So, in case anyone comes across similar scenario.
You can create custom Http Handler as a stand-alone Class Library project and use it in IIS.
On IIS Add new Application with ASP4 Integrated mode. Place your compiled DLL into bin folder (this is what i was missing all along). Seems obvious that it should be there; took some time to figure this out. :)
web.config:
<configuration>
<system.web>
<compilation debug="true" targetFramework="4.0" />
</system.web>
<system.webServer>
<handlers>
<add verb="*" path="*.ogg" name="test" type="Namespace.Classname"/>
</handlers>
</system.webServer>
</configuration>
Hope this helps.
Cheers.
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!