Reputation: 1778
I am using Serilog within an TopShelf Service, logging to the console and a rolling file. When running the service in a console my messages are written to the logfile, but when I install the service and run it no logging occurs. Is there anything special I need to configure? The file is written to the binaries folder under ".\logs\log-{date}.txt".
Upvotes: 40
Views: 21915
Reputation: 496
A lot of solutions above proposes either path hardcode, or configuring the path from .cs code. The following one allow you to use config with minimal .cs code interventions:
In .cs code:
Environment.SetEnvironmentVariable("APP_BASE_DIRECTORY", AppContext.BaseDirectory);
In appsettings.json:
"Serilog": {
"Using": [ "Serilog.Sinks.File" ],
"WriteTo": [
{
"Name": "File",
"Args": {
"path": "%SAS_BASE_DIRECTORY%/Logs/log.txt",
"rollingInterval": "Day"
}
}
]
}
Now you can change path in config without necessity to edit the code.
Upvotes: 1
Reputation: 2131
I had a similar issue, it ends up because the following code:
public static IConfiguration Configuration { get; } = new ConfigurationBuilder()
.SetBasePath(Directory.GetCurrentDirectory())
.AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
.AddEnvironmentVariables()
.Build();
the code specify the appsettings.json
file, and in that file it has the serilog's configuration setttings, but when run in service, the current folder is not point to the executable file folder. So it can not find the file appsettings.json
, and then of course Serilog won't work as expected.
Just need to change the code as following will make it work:
public static IConfiguration Configuration { get; } = new ConfigurationBuilder()
.SetBasePath(Directory.GetCurrentDirectory())
.AddJsonFile(AppDomain.CurrentDomain.BaseDirectory
+ "\\appsettings.json", optional: true, reloadOnChange: true)
.AddEnvironmentVariables()
.Build();
Upvotes: 2
Reputation: 1863
I had a very similar issue. In my case, the problem was with relative paths. I just had to specify the absolute path. Now it works like a charm.
WriteTo.RollingFile(
AppDomain.CurrentDomain.BaseDirectory + "\\logs\\log-{Date}.log"
)
Upvotes: 57
Reputation: 4371
We had the same issue, this is what we found:
Symptoms
As per @gdoten's comment, our log files were being written to \windows\syswow64 (service was running as localservice).
We believe the permissions on these files may not of allowed the durable spool file to be read causing no logs to be written to Seq.
Fix/workaround was to hard code the path of the rollinglogfile and buffer.
Upvotes: 15
Reputation: 1803
I am running as a Windows service and here is my JSON file.
{
"Serilog": {
"MinimumLevel": "Debug",
"WriteTo": [
{
"Name": "RollingFile",
"Args": {
"pathFormat": "C:\\Program Files\\mycomp\\myapp\\logs\\log-{Date}.txt"
}
}
],
"Enrich": [
"FromLogContext",
"WithMachineName",
"WithThreadId",
"WithEnvironmentUserName",
"WithProcessId"
],
"Properties": {
"Application": "MyApp",
"Environment": "Development"
}
}
}
Upvotes: 0
Reputation: 1
I wanted to read the appsettings.json and wright log files back to the application's directory, instead of the system32 directory the service was running in. Starting with this line of code fixed both issues for me.
System.IO.Directory.SetCurrentDirectory(System.AppDomain.CurrentDomain.BaseDirectory);
https://stackoverflow.com/a/10385563/8226292
Upvotes: 0
Reputation:
You can also use something like this (When you want to create a Windows Service and Serilog):
var builder = new ConfigurationBuilder()
.AddJsonFile($@"{Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location)}\appsettings.json", optional: true, reloadOnChange: true)
.AddEnvironmentVariables();
Upvotes: -1
Reputation: 197
loggerFactory.AddFile(Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "Log-{Date}.txt"));
Try this one, it worked in my ASP.NET core 2 application runs as windows service
Upvotes: 8
Reputation: 31797
It's most likely that the account under which the services is running lacks permission to write to the log file location. Try changing the log file location to the system's temp folder to see if this is the case.
If this still fails, using Serilog's SelfLog
to get exception information is your best bet.
Upvotes: 6