Annotate Serilog.Settings.Configuration as not trim-compatible

[agocke]

Unfortunately I don't have any good news for this library. It looks like the fundamental concept, loading arbitrary types by name from arbitrary assemblies, configured by the user at run-time, is fundamentally incompatible with trimming and AOT.

This at least marks it as such. Supporting a feature set like the one provided here would likely require a source generator, or build-time code generation phase.

[agocke]

PolySharp is currently missing RequiresAssemblyFiles (https://github.com/Sergio0694/PolySharp/issues/65) but the author is very responsive, so I'll wait for them to add it and then I'll pull in a new version.

[agocke]

I should also mention -- it's worth considering if this space should have an AOT-compatible solution. I think a source generator would probably be necessary.

[nblumhardt]

@agocke just thinking about:

I should also mention -- it's worth considering if this space should have an AOT-compatible solution. I think a source generator would probably be necessary.

Would this have much benefit over just relying on the C# configuration API? (The C# API can still pull values from appsettings.json directly, where parameters need to vary at deployment time..)

[agocke]

This is a good point -- I was thinking that theoretically you could use a source generator to parse the file, and then construct an equivalent graph at compile time. But that would create a potentially confusing situation where people may believe they can change the file after deployment and get different behavior -- and they can't. Making this a code-only configuration system seems like the right idea.