bartelink
commented
11 months ago In general, Serilog tries to be extremely conservative in what's made public; as you can imagine, it's hard to put the genie back in the bottle given how many things will take a dependency.
As such, it's absolutely critical to provide the maximum possible information as to your use case in order to either a) figure out a different way of doing it b) figure out a good way of exposing something that meets your need
In other words, a case needs to be made beyond "that thing, I want it, please", as you can be sure that anything that's left private/internal is for a reason, and the general idea is that the publicly exposed interface is designed to afford the access needed for the bulk of cases, but trying to avoid:
- making the exposed API more complex than it needs to be
- painting the implementation into a corner by not being able to change it in the future without breaking users
It's also normally a good idea to post your problem as a stack overflow question first, showing what you're trying to do - what you've tried etc. This can allow others to provide solutions you may not have considered.
Other things that would be useful in making such a case is a minimal implementation showing the hacking/cloning you needed to do as a workaround; often people who have tried to achieve similar things may be able to provide useful suggestions (same rule applies for stack overflow - the more you context you can provide, the better the chance of someone having useful suggestions).
bielu
0xced
Hi Serilog Team! I noticed both ConfigurationReader and IConfigurationReader have internal access, which means as developer I cannot inherith or decorate it. I have use case where possiblity of decorating would be great, but with current implementation it is impossible.