I have the following simple code:
SPDiagnosticsService diagnosticsService = SPDiagnosticsService.Local;
SPDiagnosticsCategory cat = diagnosticsService.Areas["SharePoint Foundation"].Categories["Unknown"];
string format = "Test trace logging for category {0} in area {1}";
diagnosticsService.WriteTrace(1, cat, TraceSeverity.Medium, format, cat.Name, cat.Area.Name);
I only want to write to the SharePoint ULS Logs. But this does not work. What could be the reason?
UPDATE:
Oh sorry!! I get no entries in the ULS Logs. ULS Logs are generated, but mine are not written to the Logs. All categories in diagnostics logging configuration in the CA are set to Trace level Medium and Event Level Information. There is no exception thrown, too. The code runs fine when I run it via F5 and step through it.
SOLUTION FOUND!
The AppPool Account has to be in the local Performance Log Users group! I have blogged about it here, too: http://www.bog1.de/2015/03/es-ist-nicht-moglich-in-die-uls-logs-zu-schreiben-performance-log-users/
Are you running this on the target SharePoint server?
Are you running it under a suitable SharePoint admin account?
You could try a more comprehensive example - from a google, something like http://blog.mastykarz.nl/logging-uls-sharepoint-2010/
Lastly, if you are calling this code from within a SharePoint Sandbox Solution, it will not work, you need to write a proxy. http://blog.sharepointsite.co.uk/2012/01/sandbox-solution-uls-logging.html
I couldn't find the reason why it did not work on the vm but I decided to setup a fresh one and to test after each step if my solution works.
It seems to be a config issue.
With the new machine everything works fine.
I had a similar problem, my solution was to change the monitoring level from inside SharePoint Central Administration.
Central Admin -> Configure diagnostic logging -> then select what you want log.
Related
Im having trouble with writing files to remote directory via network. The following code fails when I try to check if the directory exists:
if (!Directory.Exists(processingPath))
Directory.CreateDirectory(processingPath);
processingPath is composed like
processingPath = xxxObject.serverPath + "processing\\";
xxxObject.serverPath contains something like this
\\machineNetworkName\sharedFolder\
Its working properly, but when many requests are processing (running as tasks asynchronously), it stops working and failing into exception:
System.IO.IOException: The network path was not found.
Could you please help me what could be the problem and why it is failing after some time on network path???
Thanks for your solutions
I got the same error before, it was about authentication problems.
You have to be sure that you set properly the user on IIS, because it use a Default App Pool's identity which can't access to your NFS.
You can also use IIS virtual folders to set the identity.
(on IIS manager, see App Pool settings -> Identity and also virtual folders settings -> identity).
In my case, it worked better by using the Impersonation directly in the code, so I recommend you to use the VladL WrappedImpersonationContext Object: How to provide user name and password when connecting to a network share
Last thing to check, the owner of the files on your NFS server, if they were created under the root user, it might not work.
I had the same problem and solved it. The problem in my code and I see it in yours, too, is that you have the slash at the end of the network path.
Instead of processingPath = xxxObject.serverPath + "processing\\"; write: processingPath = xxxObject.serverPath + "processing";
My application is in C#.NET and it is deployed on different machines. Users of my application have normal access rights ( no ADMIN rights). On a few system I am getting System.Security.SecurityException. It says "System.Security.SecurityException: The source was not found, but some or all event logs could not be searched. Inaccessible logs: Security"
I did a few workarounds :-
on one machine I launched my app with admin rights, It worked fine - No issue.
I added user group in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Security.
It worked fine.
I dont want to go to every machine and do above workarounds. I need any generic workaround that can be applied once in all machine.
Any help?
Writing down a few lines of code :-
Config file :-
<add key="E_Source" Value="ABC">
C# code
Public static readonly string E_Source = ConfigManager.GetString("E_Source");
EventLog.writeEntry(E_Source, logtext, logtype);
Thanks in advance
To find the Source you want to write, .NET enumerates through all event logs. If it doesn't exist, .NET will eventually try enumerating through the Security log, for which you don't even have read rights as normal user. Thus, you get a SecurityException.
So you have to make sure that the event log exists (which AFAIK you can't do without triggering the exception). Normally, you would do that as part of your setup/install. Then, when writing, catch the SecurityException and handle it as appropriate (ex. show an error message that you couldn't write to the log).
If you're writing to the EventLog programmatically, you will need to create an event source with elevated permissions, as noted in the documentation on the EventLog class:
https://msdn.microsoft.com/en-us/library/system.diagnostics.eventlog%28v=vs.110%29.aspx
I have built an app that works only when not run as a Windows service. Well, the service runs, but it doesn't do what it should. The service uses the Local Service account. So to kick off debugging, I thought I'd start with something simple: have it create a directory when it starts:
Directory.CreateDirectory(
Environment.SpecialFolder.LocalApplicationData + "\\MyService");
When I started the service, it stopped almost immediately and Windows reported that fact. When I commented out the above statement, recompiled and re-installed, the service ran without stopping.
Obviously the above line throws an exception of some sort. I have no way of logging the error because I can't write to the file system. Any ideas why Local Service can't create a directory in its own %LOCALAPPDATA%?
You should use GetFolderPath with LocalApplicationData like so:
string folderName = Path.Combine(Environment.GetFolderPath(
Environment.SpecialFolder.LocalApplicationData),
"MyService");
Directory.CreateDirectory(folderName)
I think this might be because there is no special folder. When running as the local service account you are running under that user, not the logged in user. so you are requesting a special folder that probably wont exist, as I don't think the local service has a profile. (I may be wrong) - I was wrong :p
Just in case anyone pops by:
C:\Windows\ServiceProfiles\LocalService
is the local service profile folder, so it will end up in there.
If you want to debug it surround that line with a try catch, and then write the error to a file:
try
{
Directory.CreateDirectory(Environment.SpecialFolder.LocalApplicationData + "\\MyService");
}
catch (Exception ex)
{
System.IO.StreamWriter file = new System.IO.StreamWriter(#"C:\MyServicelog.txt",true);
file.WriteLine(ex.Message);
file.Close();
}
At least then you can see whats causing the error
Martyn
I suggest you write the exception details to the event log. All user accounts have permission to write to the event log as long as the log and source names have already been created by an administrator (which you can do simply by running the app as yourself first).
As to the root cause of the error, it may be because LocalService doesn't normally get a full set of profile folders created by default. I'm not sure whether this is by design, or simply what I have observed on various machines.
I've been updating a SP2010 solution which integrates an external content source into search via BCS. This solution deploys a feature (featureA) to the farm scope. I split it into two features, one (FeatureA) deploying to the farm scope, and one (featureB) to the site scope.
My update script does this:
Deactivate FeatureA on the farm
Update-SPSolution with the new wsp file (same name)
Activate FeatureA on the farm
Activate FeatureB on the two sites (on two different web apps)
The script bombs on the last two steps, saying
Enable-SPFeature : The Feature is either not found or not a Farm Level Feature. Use Url parameter to specify the scope of the Feature.
for the first one (farm), and
Enable-SPFeature : The Feature is not a Farm Level Feature and is not found in a Site level defined by the Url http://url-site
on the second one (sites)
This is a test run on the CI server, which means it will also crash on the production server.
However, deploying the package on my machine, and activating the features, works fine.
I've checked, the features are actually present in the SharePoint folder, so the deployment seems to have gone ok. I can't work out why SharePoint can't see them though. If I run Get-SPFeature, they are not in the list.
I've tried iisreset, to no avail.
EDIT:
I've managed to get SharePojnt to notice the two features, by using Install-SPFeature.
However, it still won't enable FeatureB, but errors out with:
Enable-SPFeature : Attempted to perform an unauthorized operation.
I'm at a bit of a loss once again.
You cannot use Update-SPSolution when new files have been added to the solution package.
From Update-SPSolution:
The Update-SPSolution cmdlet upgrades a deployed SharePoint solution in the farm. Use this cmdlet only if a new solution contains the same set of files and features as the deployed solution. If files and features are different, the solution must be retracted and redeployed by using the Uninstall-SPSolution and Install-SPSolution cmdlets, respectively.
For more information, see Adding Features during Solution Update
I'm trying to debug a webpart installed on a client's SharePoint instance. I wanted a quick and easy logging feature, so I thought of writing messages to a text file in the temp directory. SharePoint doesn't seem to like it, so what are my options?
IF you are writing to the temp directory, you will need to give the file (if it exists) or the directory rights for the IIS Application pool that the SharePoint IIS application is running under.
There are few ways of custom logging in sharepoint -
Use SPDiagnosticsService - You may write to the ULS via SPDiagnosticsService class.
Utilize diagnostics.asmx web service -
SharePointDiagnostics SharePointDiagnosticsObject = new SharePointDiagnostics();
SharePointDiagnosticsObject.Credentials = System.Net.CredentialCache.DefaultNetworkCredentials;
string Response = SharePointDiagnosticsObject.SendClientScriptErrorReport(message, file, line, client, stack, team, originalFile);
For more details on usage of diagnostics.asmx refer the following link -
https://vivekkumar11432.wordpress.com/2016/09/23/how-to-do-logging-in-uls-from-csom-in-c/
For more details on logging refer the following link -
http://www.codeproject.com/Articles/620996/Five-suggestions-to-implement-a-better-logging-in
Don't use
Microsoft.Office.Server.Diagnostics.PortalLog.LogString("Message");
According to Microsoft documentation - LogString is reserved for internal use and is not intended to be used directly from your code.
I would guess that this is a permissions issue that SharePoint is blocking you on (and probably not telling you that it is). When you try to write to a text file on the server, you need to have elevated permissions in order to do it. You can accomplish this using SPSecurity.RunWithElevatedPrivileges. Something like the following, if you want just a simple, small-code solution.
SPSecurity.RunWithElevatedPrivileges(delegate() {
using (StreamWriter sw = new StreamWriter(#"C:\log.txt"))
{
//log information here
}
});
Try a logging framework like log4net, or write a small logging framework writing into an external database, you could also use lists to log if you want to stay inside sharepoint