Support loading Serilog Sinks at runtime

[ehabelgindy]

Hi there,

I wonder if serilog can load dlls (mainly sinks) dropped in the bin directory at runtime.
This feature will allow shipping a product with a default sink, while customers can later choose to use a different sink by dropping the dll in the bin directory and provide the right configuration for it.
Here is some information about the project:

• The project I am working on is a .net core project targeting .net 462 framework, so the AppDomain exists.
• The preserveCompilationContext is set to true. (false is not an option in this project)

I can see, the code in ConfigurationReader.GetSerilogConfigurationAssemblies() support assembly scanning which is exactly what I need. However, there is no way that the ConfigurationLoggerConfigurationExtensions.ConfigurationSection(...) can pass a null DependencyContext value to trigger the assembly scanning, the logic around the DependencyContext is:

dependencyContext ?? (Assembly.GetEntryAssembly() != null ? DependencyContext.Default : null

This will only be evaluated to null if:

1. Dependency.Context.Default is null, which is not a suitable solution in my case as I need the preserveCompilationContext to be true.
2. Assembly.GetEntryAssembly() returns null, and this only happens when it's called from unmanaged code.
3. Write my own extension function that passes null to the ConfigurationSection(...). This cannot be achieved at the moment as the ConfigurationReader class is internal.

I would appreciate if you can point me to the right direction.

Thanks,
Ehab

[nblumhardt]

Hi Ehab, thanks for the post. Would creating your own custom IDependencyContext, wrapping the default one, and passing it through to ReadFrom.Configuration(), work?

[ehabelgindy]

Hi, I am sure I missing something here :). The IDependencyContext interface doesn't exist in the Microsoft.Extensions.DependencyModel package. Also, the custom dependency context should be derived from the DependencyContext anyway as this the parameter type used in ReadFrom.Configuration()

[nblumhardt]

Ah, sorry, typo on my part, I meant DependencyContext 👍

[ehabelgindy]

Was playing with this idea, there is no need to wrap the DependencyContext in another class. All is needed is to create an instance of the DependencyContext and pass a custom runtimeLibraries collection that includes the extra runtime assemblies.

Sounds simple but unfortunately the solution looks a bit hacky and I am still trying to get it to work. I believe that the DependencyContext is supposed to represent the libraries and dependencies stored in the .deps file.

Is it possible to change the access modifier of the ConfigurationReader class from internal to public?
This will allow devs to write their own extension function to set the DepedencyContext parameter to null (which is not possible at the moment)

[mihaivader]

Hi @nblumhardt,

As @ehabelgindy said, can you make the class ConfigurationReader public?

It would be really helpful in order to be able to create a Class Library that configures Serilog and other projects could use that class library without having to reference Serilog themselves.

Thank you,
Mihai

[mihaivader]

For now I've worked around this, by calling the ConfigurationReader private constructor through reflection with a list of assemblies.

[MV10]

@ehabelgindy How about an additional configuration argument that lets you override the part that resolves a null context argument? This would let the package keep the implementation details internal, as I believe they should be. For example:

public static LoggerConfiguration Configuration(
    this LoggerSettingsConfiguration settingConfiguration,
    IConfiguration configuration,
    DependencyContext dependencyContext = null,
    bool autoResolveDependencyContext = true)
{
    if (configuration == null) throw new ArgumentNullException(nameof(configuration));

    var ctx = dependencyContext;
    if(ctx == null && autoResolveDependencyContext)
    {
        ctx = (Assembly.GetEntryAssembly() != null ? DependencyContext.Default : null);
    } 

    return settingConfiguration.Settings(
        new ConfigurationReader(configuration, ctx));
}

@mihaivader You can already create a class library that uses Serilog without requiring the consuming application to know anything about Serilog. The library could even have it's own separate configuration (the consuming app wouldn't necessarily have to pass config to the library). Was your concern here maybe a side-effect of trying to resolve the NuGet transitive dependencies problem I mentioned in #90?

[ehabelgindy]

@MV10 This works for me 👍

[MV10]

@nblumhardt How do you feel about that approach? Looks harmless enough to me.

[nblumhardt]

@MV10 seems okay to me, too 👍 - just would need to be done in a non-breaking way, I think.

[MV10]

@nblumhardt Definitely non-breaking with the appropriate default value.

The more I thought about this, the less I liked my proposed parameter. The idea of "autoResolve" is more about the local decision-making process and less about choosing between loaded assemblies or DLL scanning (ie. what actually happens in GetSerilogConfigurationAssemblies). Those scenarios are so different that true/false seemed inadequate.

I'm going to PR with the following; it's a bit wordy but I think it clearly communicates the intent, though I'm happy to change it if you think it's overkill and a simple bool is better. (I think the edge case where GetEntryAssembly is null is sufficiently unlikely that it's adequate to just mention DLL scanning is the fallback in the XML comments.)

public enum ConfigurationAssemblySource
{
    UseLoadedAssemblies,
    AlwaysScanDllFiles
}

public static LoggerConfiguration Configuration(
    this LoggerSettingsConfiguration settingConfiguration,
    IConfiguration configuration,
    DependencyContext dependencyContext = null,
    ConfigurationAssemblySource onNullDependencyContext = ConfigurationAssemblySource.UseLoadedAssemblies)
{ ... }