My task is very simple, I put in the Main method two lines:
Debug.Log("App START Debug.Log");
Debug.unityLogger.Log("App", "START Debug.unityLogger.Log");
and want to see these logs in the output if the app is running. If I set the run option as Releasethe app starts, but I don't see these logs. If I set the run option as Debug and try to start, I get an error popup:
Unable to activate Windows Store app ´Template3D_pzq3xp76mxafg!App´
and the app doesn't start at all.
EDIT: according to comment of #Perazim, I have also tried:
System.Diagnostics.Debug.WriteLine("App START Debug.Log");
No effect in Release and Debug mode.
EDIT 2:
System.Diagnostics.Debug.WriteLine("App START Debug.Log");
works, if I put it in other methods, but doesn't work in the Main() method.
Debugger.Log for the output to debugger. Debug.WriteLine prints to listeners. If there is no listeners, it will not work.
My application stopped writing output to the output window with the System.Diagnostics.Debug.Writeline in debug mode. This all happened after the latest Microsoft Updates.
I created a new application just to see if it was my current application, and the new application would not write to the output window either.
Then I decided to right click on the Output Pane in Visual Studio and what do I see, Program Output unchecked.
I checked this and my Debug.Writeline works again.
In unity you can use/see debug.log(); in Visual Studio you need to use Console.WriteLine();
Related
I have this simple code in Visual Studio Code
class Program
{
static void Main()
{
Console.WriteLine("Hello!!!");
}
}
All I want to do is get the same result as when I type DOTNET RUN which prints a simple "Hello!!!" to the terminal.
Instead, if i configure it to use the terminal, I get this PATH in blue or if I try to use the debug window, I get this "You may only use..." disclaimer.
How can I set my configuration to either use one of these windows by clicking "Start with out debugging" (not via typing dotnet run manually) to print my output with out any excess info in the red boxes as seen in the images?
If there's a way to configure "dotnet run" in my settings, i'm good with that too so long the output is just "Helloo!!!" on either the debug or terminal window.
You might be able to do this by using an extension like Code Runner which works with Visual Studio Code, it is similar to Script Runner which works with the Atom editor. These are useful for reviewing simple code changes in real-time.
For Python i tried the method below.
In Visual Studio Code, click on the file and then click “RUN” at the top. find “Add Configuration” button on the menu and create a launch.json file by clicking on it. In the file, you will the line ”console”: integratedTerminal . Now change it to “console”:internalConsole. Open your code file and click “RUN” at the top again. Finally if you click on “Run without debugging” button, the output of your code will be display in “Debug Console” at where the terminal is.
Hope it works for you too.
Console.Write* works as expected when used with a console application, or a windowed application with a console attached.
However, if I make an application that does not have a console and run it from the command line, it does not output as expected. It appears to start the application asynchronously as the prompt reappears while the program is still running.
How can I output in such a way that text output will appear in an attached console or a command prompt that runs it? Or, how do I run the application differently where it waits correctly and captures the expected output?
Consider using a Logger framework, rather than relying on Console. Logging frameworks provide a variety of ways to consume their logs, so you can decide which way works best for you without having to change your code.
For example, if you're using a logging framework that's set to output log messages to the console for the sake of a console app, you only have to change one configuration option to make it output to a file, which you can use a tool like Baretail to watch even if you don't have the console open. Or you can easily change the configuration to output to System.Diagnostics.Debug so that it appears in the Visual Studio Output window.
If you're just wanting debug output to appear in Visual Studio, use System.Diagnostics.Debug.WriteLine() to output to the "Immediate" window in VS while the application is running. Wrap is in "IF" precompiler directives so that it won't happen when you compile into a non-debug build. Any lines inside the "IF" will be completely ignored by the compiler if the current build target does not have the "DEBUG" flag set (like the default "Release" build target).
#if DEBUG
System.Diagnostics.Debug.WriteLine()
#endif
I am experiencing a weird behaviour from Visual Studio 2013. I've got a C# program which writes to the standard output, let's say
using System;
using System.Threading;
namespace CsSandbox
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Hello world!");
Thread.Sleep(10000);
}
}
}
In the Debug tab of the project's properties I have redirected the output to a file, like this:
If I open the file within those 10s when my application is still running, the file does contain "Hello world!". However, as soon as the program exits, the file is cleared. This does not happen when I run the program from the command line.
Is there a rationale why Visual Studio does it? Is there a way to bypass this behaviour?
I believe this is due to the way Visual Studio hosts your application, in order to reduce startup time when debugging.
What happens is that your application (Program.exe) will actually be hosted in another process (Program.vshost.exe), which is started with the same command line arguments. When your application ends, this process is immediately restarted. You should be able to see this within Task Manager - look in the details tab so you can see the PID of the processes, and run your app - you'll see one Program.vshost.exe instance which ends when your app finishes, and another one come up immediately. That's then overwriting your output file.
One fix for this is to give your application a command line argument for the file to write to - and open that file within your Main method. You won't get there until you start running the app again.
Another option would be to simply stop using the hosting process - in the Debug part of your project properties, at the bottom you should see a checkbox for "Enable the Visual Studio hosting process". Uncheck this and I think your problem will go away - but it'll take longer to start debugging.
See this blog post for more information about the hosting process.
As I understand it now, the only way to use the remote debugger is to start the target application, and then attach to it through Visual Studio. Is there a way to capture all of the breakpoints from the very beginning of the program?
There is code within my program that I need to debug, and I can never get the debugger attached fast enough to capture that executing code.
If you can change the code, try injecting this line of code in the starting point of your app:
System.Diagnostics.Debugger.Launch();
When this line is hit it will prompt you to attach a debugger, effectively waiting for you to respond. Since you are using a remote debugger you should be able to attach at that point and then just cancel the dialog. Hope this helps.
The solution
System.Diagnostics.Debugger.Launch
didn't work for me either. However, I managed to solve my problem writing in my application start up the following:
while (!System.Diagnostics.Debugger.IsAttached)
System.Threading.Thread.Sleep(100);
That way the application will be waiting until a debugger gets attached.
On the target machine set up the Visual Studio Remote Debugger that matches the year of Visual Studio on your local machine.
Note the line that gives you the server name.
On your local machine in visual studio, open the properties of your startup project and then open the debug section.
Check the box for "use remote machine" and then enter into the text field the server name you got from the Visual Studio Remote Debugger.
Under "Start Action", select "Start External Program". Then place into the field the path to the .exe you wish to start on your target machine.
Now when you press the start button from you local machine it will start the program on the target machine with the debugger attached.
With Visual Studio Pro 2010 building a .NET 4 application, this doesn't work for me.
Apparently this is a known bug:
https://connect.microsoft.com/VisualStudio/feedback/details/611486/debugger-launch-is-now-crashing-my-net-application-after-upgrading-to-net-4-0
A (somewhat hacky) workaround for the moment which is working for me is just to have the app throw up a MessageBox() right at the start of main window initialisation:
public partial class MainWindow : Form
{
public MainWindow()
{
// To allow you time to attach a remote debugger ...
MessageBox.Show("Please attach debugger");
InitializeComponent();
...
Now you can attach the VS remote debugger at your leisure, and then hit OK on the message box.
Ugly but functional.
The correct solution for me was a combination of the answers.
The while loop will check if the debugger is attached from Visual Studio and exit the loop when it is attached.
System.Diagnostics.Debugger.Launch();
while (!System.Diagnostics.Debugger.IsAttached)
{
System.Threading.Thread.Sleep(100);
}
When I develop a C# console application (which will run on a server) and I run it using Visual Studio, I get a "Press any key to continue" message before the program terminates.
However, when I compile the very same C# code file manually using CSC, my program doesn't show that message and it terminates immediately after finishing its logic.
Does anyone know how I can make the same feature when compiling the code without using VS and WITHOUT changing the C# code any adding a ReadLine()?
UPDATE : The same message used to appear when I learned C#, I used to use TextPad with CSC, and that message used to appear without adding any Write(Line)/Read(Line) callings
It's nothing to do with the compiler - if you press F5 to debug it rather than Ctrl-F5 to run without debugging, then VS doesn't show the prompt. This is presumably so that you don't miss whatever output it's producing.
In order to do this, Visual Studio runs cmd.exe telling it to run your executable and then pause:
"C:\WINDOWS\system32\cmd.exe" /c ""...\ConsoleApplication1.exe" & pause"
It probably doesn't do it when you debug as it's a bit harder to get the process ID of a child of a child process.
To add a similar option to your program, either use a command line switch to tell the application itself to pause, or use a batch file to run it then pause, or use a shortcut with them cmd.exe /c.
That's not possible. The prompt to press any key is generated by Visual Studio when running a console app. It's not part of your program.
The only way is by using Console.Read() in your code
UPDATE: concerning your remark on using TextPad: I'm not familiar with TextPad, but I wouldn't be surprised if TextPad did the same thing as Visual Studio when running a console app.
You could do this...
static void Main(string[] args)
{
#if DEBUG
Console.Read();
#endif
}
That way the program will not wait for the console input when you build your application as a 'Release'.
You could write a batch script that runs the exe for you and prompts the user to press a key.
The batch script would look something like this:
echo off
YourApp.exe
pause
You could do this, if you want the same functionality when debugging.
if (Debugger.IsAttached)
{
Console.WriteLine("Press any key to continue . . . ");
Console.ReadKey(true);
}
This behavior has nothing to do with the compiler you are using. When you compile with Visual Studio, running the executable outside of Visual Studio actually will perform exactly the same as when you compile with CSC on the command line. Visual Studio (and TextPad) is adding the logic to add the "Press any key to continue" message on the console.
If you want your application to stay open, you will need to do something like Console.ReadLine() to block execution so that your application does not complete its execution.
The question is why would you want to have this behaviour? The Press any key to continue feature is there so that you can see the output of your application. If on the other hand you build your code and run it from a command prompt (console), this will not close when the application finishes, so you can see the output.
As noted above, the Press any key to continue is a feature of the IDE and not related to the code you are writing. The purpose of that feature is to allow you to see the output of you console application.