Migrate to an external logger provider

[TrabacchinLuigi]

The scope of this library isn't providing a logger, so using some third party abstractions is a sensible way to move away from maintain something we aren't focused on.
The actual implementation is also allocating memory when it shouldn't, and doesn't "enforce" good logging practices (like one call per log: see DokanOperationProxy where multiple log.Debug are called to write about just one event, nor using a template string instead of a variable string)

I suggest migrating to serilog, just because i know it's high performance and can be adapted to all other major loggers, or custom ones
I think also microsoft.extensions.logging.abstractions could be a good choice, but i'm not sure about performance which are quite relevant in a project like this one

[Liryna]

Hi @TrabacchinLuigi ,
That's a good idea! But I would prefer that dokan-dev/dokany#851 is taken care of first so dokan dotnet logger does not need to be changed again.
Have the wrapper set the DokanInit custom logger that uses serilog for example or anything that the user wants so that the native library logs be redirected to the C# logger and then use a native DokanLog function or maybe directly use the C# logging function in the wrapper library.

[TrabacchinLuigi]

the cool part of using a third party lib is that you don't have to work on it...
but i'm a little worried that if we build the callback interface from scratch without considering how a good logger works we could end up doing something wrong and we will need to change the driver (which is more difficult from my point of view)
A good logging interface have MANY methods with generics, don't accept only objects, because if you do that then valuetypes would end up boxed and that means instantiation. and worse if you just pass a string...
This is quite unconventional, but consider looking this video before doing that: https://www.youtube.com/watch?v=bnVfrd3lRv8&t=1s&ab_channel=NickChapsas

[TrabacchinLuigi]

Also i've pushed some modifications to my branch, it's not complete, but you can give it a spin and have a look at the serilog provided ilogger interface
When i've time i think i'll break up the modifications in branches and make some pull requests

[Liryna]

Are you talking about master...TrabacchinLuigi:feature-spans ?
Can the serilog.ilogger be implemented by whatever logger the dev would want it to be and not linked to serilog ?
If you have a proposition on how the native function pointer struct passed to DokanInit should look like from serilog.ilogger 👍 do not hesitate

[TrabacchinLuigi]

Are you talking about master...TrabacchinLuigi:feature-spans ?

Yes

Can the serilog.ilogger be implemented by whatever logger the dev would want it to be and not linked to serilog ?

Also yes, they also provide adapters to common other loggers. The only thing is the dependency on serilog package... which i don't think is something your userbase would dislike much, since it would provide better performace

If you have a proposition on how the native function ...

That would take a bit of time anyway