Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dynamic Log Filenames #40

Open
ltoshea opened this issue Jul 29, 2019 · 7 comments
Open

Dynamic Log Filenames #40

ltoshea opened this issue Jul 29, 2019 · 7 comments

Comments

@ltoshea
Copy link

ltoshea commented Jul 29, 2019

I currently am writing to a statically named log file as defined in my serilog config:
<add key="serilog:write-to:File.path" value="%LOCALAPPDATA%\App_Data\Logs\StaticallyNamedLog.log" />
I'd like to be able to change the logfile name at runtime i.e.

<add key="serilog:write-to:File.path" value="%LOCALAPPDATA%\App_Data\Logs\{appname}-Log.log" />

In log4net for example I'd set a log4net global property value for "appname" in code before the settings were read in. This would then get substituted into this path.

    log4net.globalContext.properties["appname"] = "App1"
    log4net.config.xmlConfigurator.configure("log4net.config")

Then in the logfile I'd reference it like so

%property{appname}

This would then get substituted into this path.

I've really tried to find a solution to this but to no avail - can someone offer any advice as to how I might achieve this?

@nblumhardt
Copy link
Member

You can use environment variables in Serilog.Settings.AppSettings values, so if you call System.Environment.SetEnvironmentVariable("APPNAME", "Test") at start-up, before reading from configuration, you can use %APPNAME% in the configured file path. HTH!

@ltoshea
Copy link
Author

ltoshea commented Jul 30, 2019

Thanks for your suggestion nblumhardt, this does seem like a possible solution. How about applications that are running in a context that are more confined and cannot set environmental variables. Or if you are using this as a logging class library. Each application using this would set its own environmental variable value to 'appname' and you would get in all kinds of mess.

@nblumhardt
Copy link
Member

Thanks for the reply. The same kinds of issues apply to the log4net version, don't they?

I can guess that in some *nix environments SetEnvironmentVariable() might be restricted, but I don't have any examples at hand.

Does this approach work for your current scenario?

@ltoshea
Copy link
Author

ltoshea commented Jul 31, 2019

Unfortunately not, I'm try to use serilog to provide a logging service that is used by multiple applications and would like a single unified configuration. In log4net the 'appname' property would be attached to the context of each logger meaning I can have a singular config across loggers that write to multiple files. If I understand correctly what you mean by an environmental variable, it seems with the current suggestion each logger would overwrite the previous value.

@nblumhardt
Copy link
Member

I'm not sure we're on the same page; by definition, wouldn't log4net.globalContext.properties["appname"] = "App1" also overwrite earlier values?

@ltoshea
Copy link
Author

ltoshea commented Aug 4, 2019

I don't believe so, in the case I'm describing each application has it's own log4net context - so each app could have a property called "appname" with different value (i.e. app1, app2, app3 - which would mean logging to three separate log files) They could all share the same configuration file that would have %property{Appname} in.

If we set an environment variable as suggested for serilog it's system wide - so all loggers would pick up this one value, regardless of if they are different applications.

Hopefully I'm making sense (and I'm not incorrect).
Thanks,
Liam

@nblumhardt
Copy link
Member

Ah, I think this is where we're misunderstanding each other. Environment.SetEnvironmentVariable() is not system-wide, it's process-wide. HTH!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants