Any plans on not having specific log implementation dependencies

[danielwertheim]

Was about to start evaluating your client but then saw that you have a dependency on NLog instead of the logging abstractions in .Net.

Are there any plans on changing this and get a more lean package? Why should we have to buy into a certain logging framework? What am I missing?

[pglombardo]

This is the first request to do so which I'm definitely open to. How would you prefer to see the logging? With ILoggerFactory?

[danielwertheim]

If in a project where dependency injection is used via Microsoft's IoC container construct, I guess something like services.AddHiveMq(...) which then allows you to internally use e.g. ILogger<>.

If not in an environment with dependency injection via IoC container from Microsoft, I guess we would have to provide an ILoggerFactory to HiveMqtt, similar to what is done e.g. in the MongoDB C# client, via client settings/options.

Last resort would be to hook in custom logger implementation where we would proxy the calls "manually" to the logging provider of choice (or Microsofts abstractions). I would say this one is OK if we are never meant to consume the logs that your package provide. Then you could have a HiveMqtt.Logging.NLog package that would hook into this.

[pglombardo]

Thanks @danielwertheim - I'll give this some thought and look into this soon.

[graemewelton]

@pglombardo, would you add this as an issue? I think this would be good practice.

[pglombardo]

For sure/done in #189. I'll hopefully be able to loop back to this soon.