I cannot seem to log debug statements to the "Debug Console" in VS Code using dotnet core. I have this statement in my Startup.cs:
public void Configure(IApplicationBuilder app, IWebHostEnvironment env, ILogger<Startup> logger)
{
_logger = logger;
...
}
When I print this statement from
_logger.LogInformation("Testing LogInformation");
I get output in the Debug Console, but when I run this statement:
_logger.LogDebug("Testing LogDebug");
nothing shows. I would like to do a lot of debug statements which don't carry over to production, unless I configure it to run debug statements. It seems like this would be a configuration setting. I read this post but it does not make sense to me. I seems very intuitive that the LogDebug would show a statement in the Debug Console, and if the challenge, as a link in the post states, is that "If the default was Debug or Verbose then a typical request would have hundreds of log messages flowing through, and that would probably make the log output unusable in most cases.", that challenge should be dealt with in a different way, like being able to filter the component for which debug statements are shown.
Am I missing a configuration option? Are others using LogInformation?
Related
I use log from import 'dart:developer'; but it seems that it does not print anything when I use from unit test.
What should I use for logging in both test and dev environments but not in production?
Thanks.
dart:developer only works in debug environments where the Dart vm service is available. As such, launching the unit tests with the debugger attached should work fine. It programmatically interacts with the Dart VM and debugger, so if those aren't attached it won't work properly.
However, logging can be very helpful for production environments as well, so I’d recommend migrating to a different package for a robust logging service across environments. dart:developer is not designed as a logger.
Messages sent through dart:developer log() will be handled via the Dart VM's native code implementation, note the external function definition in the src code. Tools such as the Flutter Devtools are then free to subscribe to receiving and displaying these messages.
In Flutter apps, the logging will be sent to usual app console output, however if you are using this for a Dart command line application or want output when running unit tests for Flutter apps, you should be able to see that via IDE's, in theory both the VSCode and IntelliJ Dart/Flutter plugins have explicit support added to them to display the output for log(), though currently in the case of DartCode there maybe a bug preventing that.
In theory you can also add support using the Dart vm_service package to read the log messages and send the to stdout/stderr yourself when running unit tests, but in this case it may just be easier to switch to using the logging package published by the Dart team and then you'll likely want to enable explicitly send the output to stdout and/or stderr in the Logger's listen() callback:
// pass true to enable output to stderr
Logger.root.onRecord.listen((LogRecord rec) {
final mesg = '${rec.level.name}: ${rec.time}: ${rec.message}';
if (true == useStd) {
if (rec.level >= Level.SEVERE) {
stderr.writeln('$mesg\n${rec.error}\n${rec.stackTrace}');
} else {
stdout.writeln(mesg);
}
} else {
developer.log(mesg, level: rec.level.value, error: rec.error);
}
});
See the implementation in my package for more details.
In my workflows and activities, I’d like to log some messages for debugging purposes.
I saw the cadence.GetLogger(ctx).Info() function, but don’t know where to find the logs.
Go Client:
You can use the following in the workflow code:
cadence.GetLogger(ctx).Info(...)
In the activity code, you should use the following:
cadence.GetActivityLogger(ctx).Info(...)
By default, the logger will write to console, which may be sufficient for development purposes. However, you should log to a file if you need the logs in production, too. Here is how to setup your cadence worker to do it:
workerOptions := cadence.WorkerOptions{
Logger: myLogger,
}
worker := cadence.NewWorker(service, domain, taskList, workerOptions)
The Cadence client uses zap as the logging framework. You can create the zap logger and specify the log file path per your needs. Check out the zap documentation to learn more about configuring the logs.
Java Client
The Java client uses slf4j for logging. You can get the logger instance by calling Workflow.getLogger() and configure it in logback.xml as usual.
I am doing some initial one off setup using [BeforeTestRun] hook for my specflow tests. This does check on some users to make sure if they exist and creates them with specific roles and permissions if they are not so the automated tests can use them. The function to do this prints a lot of useful information on the Console.Writeline.
When I run the test on my local system I can see the output from this hook function on the main feature file and the output of each scenario under each of them. But when I run the tests via Azure DevOps pipleine, I am not sure where to find the output for the [BeforeTestRun] because it is not bound a particular test scenario. The console of Run Tests Tasks has no information about this.
Can someone please help me to show this output somewhere so I can act accordingly.
I tried to use System.Diagnostics.Debug.Print, System.Diagnostics.Debug.Print, System.Diagnostics.Debug.WriteLine and System.Diagnostics.Trace.WriteLine, but nothing seems to work on pipeline console.
[BeforeTestRun]
public static void BeforeRun()
{
Console.WriteLine(
"Before Test run analyzing the users and their needed properties for performing automation run");
}
I want my output to be visible somewhere so I can act based on that information if needed to.
It's not possible for the console logs.
The product currently does not support printing console logs for passing tests and we do not currently have plans to support this in the near future.
(Source: https://developercommunity.visualstudio.com/content/problem/631082/printing-the-console-output-in-the-azure-devops-te.html)
However, there's another way:
Your build will have an attachment with the file extension .trx. This is a xml file and contains an Output element for each test (see also https://stackoverflow.com/a/55452011):
<TestRun id="[omitted]" name="[omitted] 2020-01-10 17:59:35" runUser="[omitted]" xmlns="http://microsoft.com/schemas/VisualStudio/TeamTest/2010">
<Times creation="2020-01-10T17:59:35.8919298+01:00" queuing="2020-01-10T17:59:35.8919298+01:00" start="2020-01-10T17:59:26.5626373+01:00" finish="2020-01-10T17:59:35.9209479+01:00" />
<Results>
<UnitTestResult testName="TestMethod1">
<Output>
<StdOut>Test</StdOut>
</Output>
</UnitTestResult>
</Results>
</TestRun>
I am trying to run Karma via node (gulp, specifically) persistently in the background but to manually re-run the tests i.e. I have autoWatch set to false. I start the server with something like:
karma_server = new karma.Server(config.karma)
karma_server.start()
Then elsewhere I would like to trigger the tests running when files are updated outside Karma. The API method that one would expect might work is server.refreshFiles(), but it does not do this.
Internally it seems like executor.schedule() might do the trick, but it seems to be undocumented, private, and inaccessible.
So when autoWatch is turned off, how does one trigger Karma testing with an existing server? I'm sure I must be missing something obvious as otherwise the autoWatch option would always need to be true for the server to be useful.
If you have a server already running you can use the karma runner to communicate with it:
var runner = require('karma').runner,
karmaConfig = {/* The karma config here */};
runner.run(karmaConfig, callback);
The grunt-karma plugin works like this, you can check it out for more info:
https://github.com/karma-runner/grunt-karma/blob/master/tasks/grunt-karma.js
I have an issue on the script, basically I don't use any log4net or whatever and im not planning, but some resource which i access during my script i suppose has some references to this log4net, so i get this messages:
log4net:ERROR XmlConfigurator: Failed to find configuration section
'log4net' in the application's .config file. Check your .config file
for the and elements. The configuration
section should look like:
I don't really care about this, as this is also not a real error, i would prefere to somehow hide this messages from the propmpt window, is this possible?
How can I ignore this information, without too much hassle?
This message comes from the log4net internal debugging, and means that not log4net configuration information is found in the config file. What I find strange is that this kind of info is usually opt-in:
There are 2 different ways to enable internal debugging in log4net.
These are listed below. The preferred method is to specify the
log4net.Internal.Debug option in the application's config file.
Internal debugging can also be enabled by setting a value in the application's configuration file (not the log4net configuration file,
unless the log4net config data is embedded in the application's config
file). The log4net.Internal.Debug application setting must be set to
the value true. For example:
This setting is read immediately on startup an will cause all internal debugging messages to be emitted.
To enable log4net's internal debug programmatically you need to set the log4net.Util.LogLog.InternalDebugging property to true.
Obviously the sooner this is set the more debug will be produced.
So either the code of one component uses the code approach, or there is a configuration value set to true. Your options are:
look through the configuration files for a reference to the log4net.Internal.Debug config key; if you find one set to true, set it to false.
add an empty log4net section in the configuration file to satisfy the configurator and prevent it from complaining
if the internal debugging is set through code, you may be able to redirect console out and the trace appenders (see link for where the internal debugging writes to) but this really depends on your environment so you'll need to dig a bit more to find how to catch all outputs. Not really simple