At various times I've desired an easy and standard way of writing some information to a log file - when a function or SmartResponse plugin fails, or even just information on what the plugin is doing.
I've played with some PowerShell functions to deliver this, but it tends to be cumbersome because you need to specify some of the same parameters over and over again each time the function is called (such as where to write the file, etc.)
I decided to tackle this by adding a class to ApiHelper.dll called Logger.
Example of Logger in use:
# Create a new instance of Logger:
$Logger = [Logger]::new("PluginName",$SrfPreferences.SysMonConfig, $PID)
# write simple log message:
$Logger.Write("this is a log message")
# write log message with a severity
$Logger.Write("beep beep. error happened", [Severity]::Error)
Contents of Log File:
# Begin Log File for PluginName at 2019-12-23T11:41:01
2019-12-23T11:41:01 SomeHost22 TestApp 61223 <Informational> - this is a log message
2019-12-23T11:41:05 SomeHost22 TestApp 61223 <Error> - beep beep. error happened
Items to consider
Need to determine the cleanest way to roll logs when they become too large or old.
Need to determine the best way to load the dll - currently it is only loaded when Enable-TrustAllCertsPolicy is called (for the first time), but now that there is another class, it may make sense to load the dll when the module is loaded.
Option added to $SrfPreferences to track when the DLL is loaded?
Option added to $SrfPreferences to store the default location of SmartResponse.Framework config? I usually use:
"SysMonConfig": "C:\\Program Files\\LogRhythm\\LogRhythm System Monitor\\config\\LogRhythm.Automation",
Caveat: once you load an assembly, you can't remove that assembly from disk until you close ALL apps using it (which typically means your console windows and your IDEs), which is mostly a pain for developers, not for production servers.
At various times I've desired an easy and standard way of writing some information to a log file - when a function or SmartResponse plugin fails, or even just information on what the plugin is doing.
I've played with some PowerShell functions to deliver this, but it tends to be cumbersome because you need to specify some of the same parameters over and over again each time the function is called (such as where to write the file, etc.)
I decided to tackle this by adding a class to
ApiHelper.dllcalledLogger.Example of Logger in use:
Contents of Log File:
Items to consider
dll- currently it is only loaded whenEnable-TrustAllCertsPolicyis called (for the first time), but now that there is another class, it may make sense to load thedllwhen the module is loaded.Caveat: once you load an assembly, you can't remove that assembly from disk until you close ALL apps using it (which typically means your console windows and your IDEs), which is mostly a pain for developers, not for production servers.
Code: