Automate logging of inputs in functions
Since time immemorial, in our company there is a public-tacit rule about logging the input to each function. And it would be okay to limit it to a simple line of Logger.LogEntering () at the beginning (although it would probably also be boring), so also our “wonderful” homegrown logger cannot get the names of functions from which it is called, and as a result, this the line expanded to an epic Logger.Log ("Classname.FunctionName - Entering") or something like that.
Not surprisingly, under the influence of recent topics about Mono.Cecil, the task of automating the process was born.
')
In order for the product to be not only intracorporate value, but also socially useful, it was decided not to limit the support of the “internal” logger, as well as to support third-party log4net and nlog (good, and for internal needs we smoothly switch to log4net).
When specifying the task, it is necessary to add calls of the logger to the beginning of the functions, as well as to log not only the fact of the input, but also the parameters with which the function was called.
Entry was delayed, and it's time to move from words to deeds.
The implementation is msbuild-task, which runs at the post-compilation stage and injects the Logger.Debug ("Entering") calls to the beginning of each function. Rather, not each, but only those marked with the [Log] attribute. Or in all functions of classes marked with this attribute. Well, or still to the beginning of each function of the module, if the [Log] attribute is injected into AssemblyInfo. If you don’t want to log any functions at all, you can mark them with the [NoLog] attribute.
In order for this msbuild task to be executed, in .csproj \ .vbproj you need to add its call. For example:
Well, or slightly changed, if you prefer log4net.
In addition, of course, you need to create an instance of the logger, in which all this will be logged. LoggingMagic currently implies that an instance of the logger is accessible through a static field of a class.
That's all. Filtering of the resulting log stream is assigned entirely to the logging library. LoggingMagic is fairly easy to expand, the attributes and class names with the logger are changed in the msbuild task settings.
A serious disadvantage is the lack of support for the logger-per-class methodology (which is promoted, for example, by nlog), logging is possible either through a static field or through a static function. In the comments, it would be curious to know how you use logging :) Per-class logging may be added if the community demands it :)
The result was a cut- off Log4Postsharp similarity, but without reference to proprietary components and without the need for linking to something third-party and supplying it during installations (loggingmagic libraries do not go further than Buildserver).
Source codes of all this disgrace are laid out on codeplex
PS I hope that the discussion about the necessity-uselessness of logging inputs is not reduced, because it is often determined by the subject area. In our particular case, this is sometimes the only way to collect detailed information when problems are detected on client installations.
Not surprisingly, under the influence of recent topics about Mono.Cecil, the task of automating the process was born.
')
In order for the product to be not only intracorporate value, but also socially useful, it was decided not to limit the support of the “internal” logger, as well as to support third-party log4net and nlog (good, and for internal needs we smoothly switch to log4net).
When specifying the task, it is necessary to add calls of the logger to the beginning of the functions, as well as to log not only the fact of the input, but also the parameters with which the function was called.
Entry was delayed, and it's time to move from words to deeds.
The implementation is msbuild-task, which runs at the post-compilation stage and injects the Logger.Debug ("Entering") calls to the beginning of each function. Rather, not each, but only those marked with the [Log] attribute. Or in all functions of classes marked with this attribute. Well, or still to the beginning of each function of the module, if the [Log] attribute is injected into AssemblyInfo. If you don’t want to log any functions at all, you can mark them with the [NoLog] attribute.
In order for this msbuild task to be executed, in .csproj \ .vbproj you need to add its call. For example:
<Import Project="c:\path\to\Logging.NLog.targets" /> Well, or slightly changed, if you prefer log4net.
In addition, of course, you need to create an instance of the logger, in which all this will be logged. LoggingMagic currently implies that an instance of the logger is accessible through a static field of a class.
// - Logger - . , .targets- public class Logger { public static NLog.Logger Log = NLog.LogManager.GetLogger("NlogConsoleApp"); }
That's all. Filtering of the resulting log stream is assigned entirely to the logging library. LoggingMagic is fairly easy to expand, the attributes and class names with the logger are changed in the msbuild task settings.
A serious disadvantage is the lack of support for the logger-per-class methodology (which is promoted, for example, by nlog), logging is possible either through a static field or through a static function. In the comments, it would be curious to know how you use logging :) Per-class logging may be added if the community demands it :)
The result was a cut- off Log4Postsharp similarity, but without reference to proprietary components and without the need for linking to something third-party and supplying it during installations (loggingmagic libraries do not go further than Buildserver).
Source codes of all this disgrace are laid out on codeplex
PS I hope that the discussion about the necessity-uselessness of logging inputs is not reduced, because it is often determined by the subject area. In our particular case, this is sometimes the only way to collect detailed information when problems are detected on client installations.
Source: https://habr.com/ru/post/114107/
All Articles