Consider Migrating to Microsoft.Extensions.Logging.ILogger

[emanuel-v-r]

Hi,

Currently, this lib is using proprietary logging interfaces, but as you know in .NET Core the standard way to do logging is using Microsoft.Extensions.Logging.ILogger, which allows having some general .NET Core convention, besides that Microsoft has some built-in implementations, and also there is a variety of third-party logging providers for these interfaces.
This allows better compatibility with .NET Core or even .NET 5 ecosystems and is easy as well to plug some alarmistics based on log level.
Have you ever considered these changes?

Thank you.

[Michael-Kempe]

Hello!
I would just like to briefly point out that this creates a dependency on an external library. Maybe there is another solution - without adding an external references?

[emanuel-v-r]

Hello!
I would just like to briefly point out that this creates a dependency on an external library. Maybe there is another solution - without adding an external references?

Hi,

I see your point, and usually, I agree that is good to avoid those, but in this scenario, it is a Microsoft package, which is quite a small one because it contains only the "contracts" and also it is also commonly used in the .NET ecosystem. You can check the package here https://www.nuget.org/packages/Microsoft.Extensions.Logging.Abstractions/, you have the statistics available there.

[gbirchmeier]

I wouldn't even call our logging "proprietary", as that implies that it's something someone would want to claim ownership of. I'd actually call it "janky" and "hacky" and "not very good".

The reason it's stayed janky for this long is because we actually have multiple loggers going on; one main one and one for each socket thread. These should really be consolidated, but doing so going to be annoying and interface-breaking so I just haven't prioritized it.

It is a mess that I'm very much looking forward to cleaning up, and I agree that ILogging is likely the best way to go. I'm hoping to attack it sometime this year.

[emanuel-v-r]

I wouldn't even call our logging "proprietary", as that implies that it's something someone would want to claim ownership of. I'd actually call it "janky" and "hacky" and "not very good".

The reason it's stayed janky for this long is because we actually have multiple loggers going on; one main one and one for each socket thread. These should really be consolidated, but doing so going to be annoying and interface-breaking so I just haven't prioritized it.

It is a mess that I'm very much looking forward to cleaning up, and I agree that ILogging is likely the best way to go. I'm hoping to attack it sometime this year.

Great! Thanks for the feedback!

[abbeycode]

Hi! My company's been using QuickFIX/n for a couple of years now, and we'd like to dedicate some time (essentially a Summer project) to improving the logging situation, and we agree that moving to ILogger would be the best way to go.

Our key complaint is the lack of rolling, though it would also be nice if the QuickFIX logs could be co-mingled with our own and filtered by severity.

If we were to start working on adopting Microsoft.Extensions.Logging.ILogger, would that PR be welcome? We have a junior developer who we'd be putting on this with my guidance and could use any pointers as far as where to start (e.g. the classes we would we be looking to eliminate in switching to ILogger).

[kirsan31]

For now we can somehow integrate popular logging framework (like NLog) but we unable to do proper message filtering and message severity.
It wood be nice to have more control of logging. For example I want not to log HeartBeat messages at all. And i don't want to do it by parsing the final message string :(