I'm using Serilog from within my website & web API all good.
Now I want to use Serilog from within WCF.
But when I new up a LoggerConfiguration and create a logger from within WCF, the logging doesn't seem to work? Eg nothing is being output to the text file.
var seriLog = new LoggerConfiguration()
.WriteTo.File(#"C:\Serilogs\myapp.txt")
.CreateLogger();
seriLog.Debug("log message");
Ultimately I want to write to Seq from within the WCF service.
What am I missing or doing wrong?
Has anyone got some working code samples of how this would be done?
Are there tricks to using the Serilog/Seq stack from within WCF?
There are a couple of things to that come to mind-
First, is the setup code here being executed only once, i.e. at application startup, so there is exactly one logger pointing to the text file? Only one instance of the logger can use the file at a time.
Next, is the process running with permission to access the file?
Last, is the file open e.g. in Notepad or another app that might have it locked?
If none of these spark any ideas, you can set up Serilog's self-log before configuring the logger:
SelfLog.Out = Console.Error;
This should get shown in the VS debugger, so if Serilog's catching and suppressing any exceptions you should see them.
If you can't run it in a debugger, try:
SelfLog.Out = File.OpenText(#"C:\loglog.txt");
Sometimes I find running the app under the debugger with "Break on all exceptions" enabled can be a quick way to get to the bottom of it, too (Ctrl-D,E -> CLR Exceptions [x] Thrown, [x] Unhandled).
Related
Our application is using CefSharp version 73.1.130. The issue only occurs on a small number of internal workstations within our organization. Worth noting, we are also seeing the same error with CefSharp version 92. Another strange thing is that it the issue is consistent, but only when the web apps are launched through certain navigations. Other navigations work consistently for these users.
We use RegisterJsObject to register a javascript object with browser. If I understand correctly, asynchronous binding is preferred moving forward.
The issue presents as strange/unexpected behavior in the hosted web application due to failure to retrieve context from the host WinForms application. The behavior would suggest a failure to register/bind the js object with the RegisterJsObject method. However, that method is not throwing an exception.
Enabled Cef logging showed the following error:
ERROR:JavascriptRootObjectWrapper.cpp(34)] IBrowserProcess is null, unable to bind object
After looking into the code, it appears the location that the value pointed to by "IBrowserProcess" is set is in WcfEnabledSubProcess::OnBrowserCreated (https://github.com/cefsharp/CefSharp/blob/cefsharp/73/CefSharp.BrowserSubprocess.Core/WcfEnabledSubProcess.cpp). I was able to build CefSharp and add additional logging to that method.
On my workstation (I'm not affected by the issue), I get through OnBrowserCreated with no exceptions. However, on my coworkers workstation I see the following line is failing:
...
channelFactory->Open();
auto browserProcess = channelFactory->CreateChannel();
auto clientChannel = ((IClientChannel^)browserProcess);
try
{
clientChannel->Open(); <-- FAILS
browser->ChannelFactory = channelFactory;
browser->BrowserProcess = browserProcess;
}
catch (Exception^)
{
}
}
With the error:
There was an error reading from the pipe: The pipe has been ended. (109, 0x6d)
Has anyone seen this issue before? I'm not sure how much this will help, but does anyone know if it's possible to enable WCF tracing with the CefSharp.BrowserSubProcess.exe. I have been trying this, but no luck so far.
I'm setting up a pretty simple ASP.Net Core (2.2) MVC Web App. I want to be able to see any application errors (500s) and what caused them so it seems like Application Insights is the place to look.
If I go into Application Insights / Failures (Operations Tab - see screenshot below), I'm able to see a graph/count of all the 500 errors. I can click on "DRILL INTO" button and see a lof of the details (Event Time, Request Name, etc...) but cannot seem to get any details on the actual cause of the error / line number.
Basically, I have the exact same problem as this person:
Azure Monitor / Application Insights not showing stack trace for errors
(my screenshots look identical).
When I drill down to the exception details, I get something like this:
I'm want to get something like this:
I did see info on adding Application Insights via Nuget to my solution and putting
services.AddApplicationInsightsTelemetry();
into the Startup/ConfigureServices method.
I also see that you can look at Kudu logs, etc... but I really want this all to be easily accessible in Application Insights.
Any suggestions?
OK - I think I solved my own problem. Turns out I had added Serilog a while back (sort of forgot about that) and it was capturing all the errors before getting to AI. When I removed the Serilog configuration code from Program.cs and Startup.cs, the application exceptions started showing up in Application Insights / Failures along with the full Call Stack. Thanks for your suggestions!
A 500 Internal server error suggests you are looking for the stack trace to identify what went wrong and where. No code has been provided in your example but you will need to surround your code with a try catch and then log the exception to get the stack trace or you can use the TelemetryClient as below:
var telemetry = new TelemetryClient();
...
try
{ ...
}
catch (Exception ex)
{
// Set up some properties:
var properties = new Dictionary <string, string>
{{"Game", currentGame.Name}};
var measurements = new Dictionary <string, double>
{{"Users", currentGame.Users.Count}};
// Send the exception telemetry:
telemetry.TrackException(ex, properties, measurements);
}
Further information can be found at Microsoft
Im trying to filter my input to application insight by configuration. Im sending data from SeriLog with the ApplicationInsightsTraces-sink as can be seen below in my configuration:
Log.Logger = new LoggerConfiguration()
.ReadFrom.Configuration(Configuration)
.WriteTo
.ApplicationInsightsTraces(Configuration.GetSection("ApplicationInsights")
.GetSection("InstrumentationKey").Value)
.CreateLogger();
This code sends the correct data to the "Trace" in Application Insights but AI gets the traces from somewhere else also. I guess the framework in some way? I would like to turn off the standard logging of traces from the framework so that I can use only one filter for what to log (loglevel and specific overrides for example "Microsoft.AspNetCore": "Warning". I would prefer to not filter in a processor for each Trace. Any ideas?
It seems to be working the way I want it to when I reset the options object by row provided below. Im not exactly sure which property in ApplicationInsightsServiceOptions that did the change.
services.Configure<ApplicationInsightsServiceOptions>(
options => Configuration.GetSection("applicationInsights").Bind(options));
I have a problem with WCF. My testing code is pretty simple.
I call a service layer method on my server from my silverlight application and print the result in a textbox.
Everything of this is surrounded by try-catch.
When my service layer method simply returns a constantly defined string there seems to be no problems - however as soon as it calls a more complex method it fails.
While debugging it does not even reach the complex model method; it fails before that inside some auto-generated code from microsoft:
/WuSIQ.jpg
As the error message "NotFound" is not exactly the most helpful or specific you can imagine my trouble googling for hints.
I thought maybe the auto-generated code could only send simple data so I made a temporary string and returned that, but this did not help.
I have already: a client access policy, a service reference added, removed duplicate reference in ServiceReferences.ClientConfig and a ServiceLayer.svc.cs.
I am debugging by running from the main window and my breakpoints are picked up.
Anyone?
I had some errors in the server side method that were quickly found after debugging was fixed.
I fixed this, as I said in comments, setting the project to have "Multiple Startup Projects".
Whenever I had troubles with updating the WCF service methods one of these usually solved it all:
1 Delete all bin and obj folders (specifically selecting re-build might do the same).
2 The servicelayer will not succesfully auto-update (but will work!) unless this:
[ServiceContract(Namespace = "")]
... is set to this:
[ServiceContract(Namespace = "YourServiceLayerName")]
3 Right clicking on the servicereference and selecting "update...".
Sometimes it would stop debugging again, but a forced full re-build would return it to normal.
I hope this helps someone.
I am currently refactoring an application that prints its status to the console window. At the moment I am doing something like this:
Console.Write("Print some status.....")
//some code
Console.WriteLine("Done!")
Now while this works fine, all the logic is hidden between console.writelines and I find makes it very hard to read.
I don't know if there is a better way of doing this, but I just wanted to ask and see if anyone has come up with a better/more clean way of print application status to the console.
Any ideas?
Take a look at Log4Net, it handles everything, but might be an overkill for your app, no idea. However knowing Log4Net will likely help you down the road someday so maybe this is a good chance too learn it.
I second using Log4Net. It is pretty easy to use it without invoking the difficult parts - just do the following:
In your applications Main() method, call
log4net.Config.BasicConfigurator.Configure(new log4net.Appender.ConsoleAppender());
That sets up a basic Console logger that logs all messages to stdout.
In the class that needs logging, create a new ILog like so:
private static readonly log4net.ILog log = log4net.LogManager.GetLogger(typeof (MyClass));
Then in the method that needs logging, call
log.Debug("Print Some status ...");
Once you have all of this set up and working. look through the Log4Net documentation on how to set up more useful logging. You can do a lot of different types of logging without changing the logging calls in your code at all.
Why not use a Logger object that write errors into a text file? You could come with some "priority" error messages such as: Logger.print(new priority("important"), "blabla");
This way, you could find in your file the exact time and all the message you want.
If you absolutely want the console, you could use the priority on the console.. so it would only prints what you tell the logger to print, such as network error, etc..