using System;
namespace ConsoleApp2
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Hello World!");
}
}
}
Code is perfect and simple.. you know :D
but the editor is empty? Whats the matter?
I first suggest you go to "Tools->Options->Debugging" and then make sure the checkbox at "Close the console when debug ends" (4th element from the bottom) is not checked. That will leave the console window open when the application exits.
Try running with Ctrl-F5.
This starts without the debugger and keeps the window open after the program ends.
I always set up a button for it each VS install, to make my life easier.
and the results:
Is there a way to redirect the original program output to XUnit output?
All i could find is how to print output from XUnit tests (see here)
With "original output" i mean that for each time i write Console.WriteLine or similar in my program i want that output to be there when i look at test results.
I know that it is possible to redirect console output to a different textwriter (source), how can i set up my tests so that all output is redirected to Xunit?
This is a little work but it is achievable.
Like you mentioned, you came across ITestOutputHelper. With a bit more effort, you can redirect the Console output to a new class that implements the TextWriter.
So from this, if you put together something like:
public class RedirectOutput : TextWriter
{
private readonly ITestOutputHelper _output;
public RedirectOutput(ITestOutputHelper output)
{
_output = output;
}
public override Encoding Encoding { get; } // set some if required
public override void WriteLine(string? value)
{
_output.WriteLine(value);
}
}
And in you test constructor (which I suspect the piece you are missing?):
public class UnitTest1
{
public UnitTest1(ITestOutputHelper output)
{
Console.SetOut(new RedirectOutput(output));
}
...
}
This is where we are doing a redirect from the Console to ITestOutputHelper .
The downside of this is that you will NEED to override EVERY use of a Console.Write call you use in your code. So RedirectOutput can end up quite large. See ms docs here for a list overloads.
I don't know of any other way - I would have hoped it would be simpler. Surely there is another solution somewhere.
But at least this will get you going, if you havent already.
Also might be worth a rethink of design around using Console writes in your code. Perhaps something around a custom interface output?
I am relatively new to .net world, I have a solution where there are hundreds of Debug.Writeline and Debug.Write.
I need to send the message to a text file and a database instead of traditional output.
replacing all Debug.XXX line and sending those particular messages to my destinations is tedious and not recommended task.
so how should I hook up an alternative destination ?
One way is to override Debug.Write() functionality, which is not working.
kindly help me and thanks in advance
You can inherit your own TraceListener:
public class MyTraceListener : TraceListener
{
// called (in debug-mode) when Debug.Write() is called
public override void Write(string message)
{
// handle/output "message" properly
}
// called (in debug-mode) when Debug.WriteLine() is called
public override void WriteLine(string message)
{
// handle/output "message" properly
}
}
You then need to register an instance of this class (using Trace.Listeners.Add():
var myListener = new MyTraceListener();
Trace.Listeners.Add(myListener);
Now all calls to Debug.Write() and Debug.WriteLine() are forwarded to the respective methods of your instance of MyTraceListener. Note however that this only happens in DEBUG builds. In RELEASE builds, calls to Debug.Write() and Debug.WriteLine() don't do anything.
I'm sure there's some simple answer, but none of the other Stack Overflow posts has helped me. My code will not log to the Console, and it's hard to do anything useful with that state of affairs.
using System;
using System.Diagnostics;
namespace Learning
{
class MainClass
{
public static void Main (string[] args)
{
Debug.Log ("this?");
Debug.Print ("How about this?");
Console.WriteLine ("WORK");
Console.ReadLine ();
}
}
}
I've been able to write to the console before, I don't know why it's being persnickety now.
Probably because your code doesn't actually compile. Log() is a static method of Debugger, not Debug, and it takes three arguments: level, category, and message.
public static void Main (string[] args)
{
System.Diagnostics.Debugger.Log(1, "category", "this?");
System.Diagnostics.Debug.Print ("How about this?");
Console.WriteLine ("WORK");
Console.ReadLine ();
}
It's worth noting that Debug/Debugger methods will not do you any good unless you are Debugging. To start a debugging session in mono, go to the Run -> Debug
You may want to check what kind of application you are using. For example, if you are making a Forms Application, you won't have access to the Console functions.
You can change this by going into the Solution Properties, and changing it from a Windows Forms Application to a Console Application. This won't have any effect on your program, other than it will run a Console alongside.
When doing a console application in Java with Eclipse, I see the output being put in a text box in the IDE itself, instead of having a console popping up like in Visual Studio. This comes in handy, as even after the program has exited, I can still make good use of the text that was written in it, as it doesn't get erased until I run it again. Is it possible to achieve anything like that with Visual Studio? I know that instead of doing
System.Console.WriteLine(str);
I can do
System.Diagnostics.Debug.WriteLine(str);
but it is not quite the same thing, as you get a lot of "junk" in the Output window, as all the loaded symbols and such.
Even better, is it possible to have everything done in the IDE itself, when you run your application, instead of having the console running?
In the Tools -> Visual Studio Options Dialog -> Debugging -> Check the "Redirect All Output Window Text to the Immediate Window".
In the Visual Studio Options Dialog -> Debugging -> Check the "Redirect All Output Window Text to the Immediate Window". Then go to your project settings and change the type from "Console Application" to "Windows Application". At that point Visual Studio does not open up a console window anymore, and the output is redirected to the Output window in Visual Studio. However, you cannot do anything "creative", like requesting key or text input, or clearing the console - you'll get runtime exceptions.
Use System.Diagnostics.Trace
Depending on what listeners you attach, trace output can go to the debug window, the console, a file, database, or all at once. The possibilities are literally endless, as implementing your own TraceListener is extremely simple.
You can try VSConsole which allow you to integrate its console window inside VisualStudio as dock panel at bottom. To use this you have to
Add VSCodeExtension to VisualStudio
Add VSCode NugetPackage reference in your project.
Add using Console = VSConsole.Console; as namespace reference in *.cs file
change the Output type from Console Application to Windows Application to hide the main console window that pops up when you run your console application.
Then your application will use VSConsole.Console class insted of System.Console class.
It's time to check the latest release/s for Visual Studio, folks. The most suggested solution that did not work for some of you before might work now.
In Visual Studio 2017 (Release Version 15.4.2 and above), going to Tools > Options > Debugging > General > (Check Box) Redirect all Output Window text to Immediate Window has worked for me.
Few Notes:
To see the Immediate Window, make sure that you are in Debugging mode.
There should now be 3 other debugging tools available at your disposal, namely, Call Stack, Breakpoints, and Command Window, as shown below:
Best wishes!
You could create a wrapper application that you run instead of directly running your real app. The wrapper application can listen to stdout and redirect everything to Trace. Then change the run settings to launch your wrapper and pass in the path to the real app to run.
You could also have the wrapper auto-attach the debugger to the new process if a debugger is attached to the wrapper.
A simple solution that works for me, to work with console ability(ReadKey, String with Format and arg etc) and to see and save the output:
I write TextWriter that write to Console and to Trace and replace the Console.Out with it.
if you use Dialog -> Debugging -> Check the "Redirect All Output Window Text to the Immediate Window" you get it in the Immediate Window and pretty clean.
my code:
in start of my code:
Console.SetOut(new TextHelper());
and the class:
public class TextHelper : TextWriter
{
TextWriter console;
public TextHelper() {
console = Console.Out;
}
public override Encoding Encoding => this.console.Encoding;
public override void WriteLine(string format, params object[] arg)
{
string s = string.Format(format, arg);
WriteLine(s);
}
public override void Write(object value)
{
console.Write(value);
System.Diagnostics.Trace.Write(value);
}
public override void WriteLine(object value)
{
Write(value);
Write("\n");
}
public override void WriteLine(string value)
{
console.WriteLine(value);
System.Diagnostics.Trace.WriteLine(value);
}
}
Note: I override just what I needed so if you write other types you should override more
I know this is just another answer, but I thought I'd write something down for the new Web Developers, who might get confused about the "Change to a Windows Application" part, because I think by default an MVC application in Visual Studio 2013 defaults to an Output Type of Class Library.
My Web Application by default is set as an output type of "Class Library." You don't have to change that. All I had to do was follow the suggestions of going to Tools > Options > Debugging > Redirect all Output Window text to the Immediate Window. I then used the System.Diagnostics.Trace suggestion by Joel Coehoorn above.
Instead, you can collect the output in a test result.
You can't supply input, but you can easily provide several tests with different command line arguments, each test collecting the output.
If your goal is debugging, this is a low effort way of offering a repeatable debugging scenario.
namespace Commandline.Test
{
using Microsoft.VisualStudio.TestTools.UnitTesting;
[TestClass]
public class CommandlineTests
{
[TestMethod]
public void RunNoArguments()
{
Commandline.Program.Main(new string[0]);
}
}
}
regarding System.Diagnostics.Debug producing a lot of "junk" in the Output window:
You can turn that off by right clicking in the output window. E.g. there's an item "Module Load Messages" which you want to disable and an item "Program Output" which you want to keep.
You have three possibilities to do this, but it's not trivial.
The main idea of all IDEs is that all of them are the parents of the child (debug) processes. In this case, it is possible to manipulate with standard input, output and error handler. So IDEs start child applications and redirect out into the internal output window. I know about one more possibility, but it will come in future
You could implement your own debug engine for Visual Studio. Debug Engine control starting and debugging for application. Examples for this you could find how to do this on learn.microsoft.com (Visual Studio Debug engine)
Redirect form application using duplication of std handler for c++ or use Console.SetOut(TextWriter) for c#.
If you need to print into the output window you need to use Visual Studio extension SDK.
Example of the second variant you could find on Github.
Start application that uses System.Diagnostics.Debug.WriteLine (for printing into output) and than it will start child application. On starting a child, you need to redirect stdout into parent with pipes. You could find an example on MSDN. But I think this is not the best way.
If you need output from Console.WriteLine, and the Redirect All Output Window Text to the Immediate Window does not function and you need to know the output of Tests from the Integrated Test Explorer, using NUnit.Framework our problem is already solved at VS 2017:
Example taken from C# In Depth by Jon Skeet:
This produce this output at Text Explorer:
When we click on Blue Output, under Elapsed Time, at right, and it produces this:
Standard Output is our desired Output, produced by Console.WriteLine.
It functions for Console and for Windows Form Applications at VS 2017, but only for Output generated for Test Explorer at Debug or Run; anyway, this is my main need of Console.WriteLine output.
If you are using same methods on Console that are available in Debug class like Console.WriteLine(string) then in .net core you can add below line as your 1'st line in program.cs file.
global using Console = System.Diagnostics.Debug;
using System.Diagnostics;
Now all your call for Console.WriteLine(string) are executed as Debug.WriteLine(string) in all *.cs files in project. At places where you want to explicitly use console methods like Console.Readline() then you have to replace it with fully qualified class name System.Console.ReadLine().
Now output from all your Console.WriteLine(string) is now visible in Visualstudio output window. You can further filter out noise in output window by selecting what type of messages you want to see in that window as shown below
Similar to #Sarel Foyerlicht's answer, the only way it work on my side is routing to debug output using this (complete) wrapper.
public class DebugTextWriter : StreamWriter
{
public DebugTextWriter() : base(new DebugOutStream(), System.Text.Encoding.Unicode, 1024) { this.AutoFlush = true; }
sealed class DebugOutStream : Stream
{
public override void Write(byte[] buffer, int offset, int count) { Debug.Write(System.Text.Encoding.Unicode.GetString(buffer, offset, count)); }
public override bool CanRead => false;
public override bool CanSeek => false;
public override bool CanWrite => true;
public override void Flush() => Debug.Flush();
public override long Length => throw new NotImplementedException();
public override int Read(byte[] buffer, int offset, int count) => throw new NotImplementedException();
public override long Seek(long offset, SeekOrigin origin) => throw new NotImplementedException();
public override void SetLength(long value) => throw new NotImplementedException();
public override long Position { get => throw new NotImplementedException(); set => throw new NotImplementedException(); }
};
}
which is utilized by rerouting via
System.Console.SetOut(new DebugTextWriter())