Perhaps this could move down to the if ((toTypeInfo.IsInterface || toTypeInfo.IsAbstract) && !string.IsNullOrWhiteSpace(value)) block? If it's first up, here, we might hit issues where this is ambiguous, e.g. the target Type is string.

That was my initial implementation, but then I thought it would be strange to limit it to only abstract classes and interfaces, because after all this can also be useful in other cases, like for sinks that accept complex parameters that are not abstract nor interface (for instance : EmailConnectionInfo in Serilog.Sinks.Email , ColumnOptions for Serilog.Sinks.MSSqlServer ...)

This also gives a workaround for configuration that cannot be easily defined with the key-value settings syntax, by allowing to define it as code in a static property.

Also, I've tried to make the regex for static-property accessor as specific as possible to avoid false positives.

What do you think ?

@nblumhardt any opinion on the subject? :)

I think it's a fair consideration - just not sure if it's behavior we want to commit to yet in this PR. (We'd also then need to consider whether assembly-qualified type names should be supported in more places, since subclassing is a possible workaround for other scenarios, plus look at how this would interact with some kind of "structure" syntax for populating fields of complex configuration parameters down the track).

TL;DR: I don't think it's a bad idea - just might be scope creep for this PR, since we haven't really dug through all the possible implications :-) .. what do you think?

That makes sense 👍
Easier to make it support a few use cases initially and extend it later on if needed.

Thanks !

Probably, for a better UX could we also use full type names without specifying assembly? We could look for the target type in configuration assemblies (using section) something like:

var accessorType = Type.GetType(typeName) ??
            _assemblies.SelectMany(a => a.ExportedTypes)
                        .FirstOrDefault(t => t.FullName == typeName);

If we do that for members, could/should we do the same thing for instances?

For now I've tried to not deviate too much from the way arbitrary sub-types (for interfaces and abstract classes) are referenced, that is with full assembly-qualified type names. Maybe lifting that restriction would be nice, but I would keep it as a separate issue / PR.

Sounds good

Perhaps we could also add support for the public static fields at the same time?

I have mixed feelings about accessing arbitrary fields, but I guess if they are public, they are part of the public API so technically accessible. I'll include public fields as well. 👍