Join 34,000+ subscribers and receive articles from our blog about software quality, testing, QA and security.

No events prior to logging / can't override logging methods


I’ve been playing around with this logging tool for a little while now as I’m evaluating several potential tools for a fairly large upcoming project that is going to require extensive logging…

I have designed all my modules to have multiple logging levels of which I can set in the App/Web.config to determine whether I want Errors, Warnings, Informational, Verbose, Debug, etc. In the code I have to make the determination of whether or not I perform each specific logging call based off of the value set for the module via an if statement -OR- making a call through a “wrapper” class that will make the call based off of the value (each logging call is tagged with what level it will log on and compares it with the config files value).

The question: Is there anything built into the API (perhaps I overlooked it) or any future plans to create events that will be fired off prior to any of the logging method calls actually being executed so that you can intercept and optionally discard the call if needed (or whatever else you may want to do)?

For example, I can call SiAuto.Main.EnterMethod(this, “TestMethod”, new object[] { LoggingLevel.Verbose }) and have the call run through another method where I can discard it if logging is not at “Verbose” level.

I see the few events that you can handle and they all fire off after the logging action occurs which doesn’t help. Also, there isn’t anything built to allow you to opt out of the logging action either…

Of course, my first thought was to see if I could merely create a new class inheriting from SiAuto so I could override the methods that I’m using to perfrom the checks I need but quickly found out that it is a sealed class :wink:

Great logging tool at any rate, one of the best I’ve seen to date…

Any ideas? Thanks!


Hello Travis,

Thanks for your interest in SmartInspect. First, you can ‘simulate’ log levels by using different session objects for the designated log levels. You would add a session object for each logging level and disable and enable them via the Active property of the session to enable or disable a log level. To log errors, you would then use your Error session object, for warnings the Warnings session object and so on. This is not the optimal solution, but it’s a good way to simulate log levels.

We are currently working on the 1.3 release of SmartInspect and the good news is that SmartInspect will get support for logging levels because many of our customers already requested it. I cannot promise any specific date for the 1.3 release, but we expect it to be released in January. Additionally, a new filter event will make it possible to filter any log packet before it’s processed.

For further questions you can also contact me directly. Thanks!


Thank you for your response Dennis; creating multiple instances of the Session object appears to be a viable solution to the logging level problem.

Sounds like the plans for the next version will address most (if not all) of the things I’ve run into in my “interrogation” of the API over this past weekend.

Thanks again –