Develop Reference

When something is highlighted in a debug console, execution just pauses until it's unhighlighted ... how do I stop this behaviour?

I start a visual studio project with debugging.
The console pops up, and I often accidently highlight something, which causes execution to pause until I unhighlight it ... I don't want it to pause ever unless I've set appropriate breakpoints.
I've tried looking around at the various options, but nothing seemed appropriate.

This superuser response answers the question.
https://superuser.com/questions/1442941/windows-10-console-stops-running-if-i-click-in-the-console-window
Basically a change in behaviour since windows 10 where QuickEdit was enabled by default, so highlighting the console would cause the console to stop printing and pause the program. By disabling QuickEdit it will not longer pause.

How to set breakpoints to all lines in a c# file in visual studio?

I am working with Visual Studio 2015.
I have a big c# class file with lot of properties and methods. I want to set breakpoints to all possible lines (set and get of properties, methods) at once. How can I do that?

You could add Debugger.Break() on the end of every single line. Therefore you could use the search and replace function of visual studio and replace \n with Debugger.Break()\n (Remember activating the regular expression option). This would cause the debugger to break at every single line, even though you won't have an indicated breakpoint.
I don't think that there's a method to add normal vs breakpoints to every single line though, due to the fact that it's quite useless, considering that you normally just step through the code with F11.

I think you are looking for this,
steps to follow:
1) Add a break point on the first line of code you want to debug.
2) Run the application.
3) When you want to run the next line of code, Select Debug | Step Into
4) Repeat step #3 for each line of the code

With vim (vsvim) you can set a breakpoint, move down a line, then repeat however many times you like, eg:
{Escape}qq:vsc Debug.ToggleBreakpoint{Enter}jq100#q
will set breakpoints on the next 100 lines
edit: here is example video, wouldnt let me embed gif https://imgur.com/SFhlEr7

Step Into(F11) or use the Debugger.Break() or add breakpoint directly would be the workarounds for you, of course, I suggest you use the Step Into(F11) which was much more convenient.
If you could use the latest VS2017 version, it has a new feature "Run to Click" which is also a better workaround for you during debugging.
Actually you don't have to debug every line code, that's also the reason I suggest you use this new feature.
Run to Click: Simply click the icon next to a line of code while debugging to run to that line. No longer set temporary breakpoints or
perform several steps to execute your code and stop on the line you
want. Now while stopped at a break state under the debugger, the Run
to Click icon subtly appears next to the line of code that your mouse
is hovered over. Move your mouse to the icon and click the button, now
your code will run and stop on that line the next time it is hit in
your code path. Turn it off from Debug> Options > Enable Run to
Click.
Reference:
https://www.visualstudio.com/en-us/news/releasenotes/vs2017-relnotes

Open a feature request with Microsoft https://learn.microsoft.com/en-us/visualstudio/ide/suggest-a-feature?view=vs-2022
There should be a mode that visual studio can be put in so that it automatically stops on every line of code in a particular project. This would be VERY valuable when you attach the debugger to a pre-existing process and you don't know where in the app is the current point of execution is, ie: web apps where you do not know the entry point.

How to see output of a C# console program when running in VS?

I just wrote a clever program called helloworld. It's a C#/.NET 4.5 console app. Deep within the twisted nested mazes of logic there's use of Console.WriteLine().
When I'm running this at a command line, it runs and I see the output. I can do other commands and mess around a bit, and later scroll up to see the output again.
Now I'm in Visual Studio, tweaking the source ("Hi" is more efficient than "Hello") and testing by tapping F5. What happens is a console window pops up and immediately vanishes. I have no idea what the program printed. How can I see the output?
I don't want to modify my source at all. After searching for solutions, I find some who say to use Console.ReadKey() - but then it would suck to be using the program at the command line. There's no real reason the user should have to tap a key when the program has already done its work. Even if i go with this, there's the problem of the output disappearing when the console window closes after a key tap.
I don't want to use Debug.WriteLine() which does write to the output window in VS, but doesn't write ordinary output for the end user to see.
I have discovered ctrl-F5, which runs the program as if it had a final Console.ReadKey() line, but there's still the problem of when I tap any key, all the output vanishes along with the window. Three minutes later, I'm thinking "Oh wait, did it print 'Hello' or 'Helo'?" No way to check.
Seems like the Visual Studio IDE should somehow capture all that a freshly built program writes to its stdout or the Microsoft equivalent thereof, and show it in its "Output" panel, or some panel, for later scrutiny. Maybe it does do this, and I don't yet know the trick to it? Seems like this would be a common desire among millions of C# developers.

If you're working on a .NET Core console application (or .NET Framework via the .NET SDK) using Visual Studio 2019, the behaviour of leaving the console window open after the program has executed will now happen by default:
Specifically:
This should prevent the need to add Console.Read() calls to console apps to prevent the console window from closing immediately after the program has finished executing. The launched console window is also re-used for subsequent runs, so if you’re used to using ctrl+f5, you won’t have lots of console windows to close after you’ve launched your application a few times.

The reason it closes automaticly is because it's done running the program. If you want to see what it did, make it need a new command like hitting any key. The Console.ReadKey(); pauses it and waits for a User to hit a key to continue. Put that command after the commands of instruction you are doing and it will pause it until you hit any key.
Console.ReadKey(); // Pauses until you hit any key

You can also run your program pressing F10 (executes one line by one), with F11 (goes inside a function).
The other option you have is to set breakpoints in Visual Studion and run the program by pressing F5 - it will stop at the next breakpoint. And the breakpoints can have conditions - i.e. conditional breakpoints.

Some options are:
1. wrap #if DEBUG around Console.ReadKey()
2. run directly from an open terminal
3. create a Test project - but again you'll need Console.ReadKey() to stop it closing.

c# force debug mode programmatically

Nevermind why one might want to do this, I'm just curious to know if it can be done.
Here's my code that doesn't work:
if (!Debugger.IsAttached)
{
try
{
Debugger.Launch();
while (!Debugger.IsAttached)
{
Thread.Sleep(1000);
}
}
catch (System.Security.SecurityException e)
{
Console.WriteLine("exception " + e.Message);
}
}
Basically I was curious to know how to use the Debugger.Launch() method.

Debugger.Launch will launch a debugger or will do nothing is one is already attached. I believe It's not a breakpoint. Debugger.Break() will actually break.
Calling Debugger.Launch() may do different things depending on the machine, for example if Visual Studio is installed or not, etc.
See also a related tech article: How to: Launch the Debugger Automatically

It will launch and attaches a debugger to the process.
For sure do not use it in production . I think that possible use
can be in local machine when error occured and you want automatically run debug.

I think you're misunderstanding what Debugger.Launch() does. It functions like a hard-coded breakpoint.
When your program hits Debugger.Launch(), the Just-In-Time-Debugging window will show (assuming you have Visual Studio installed on the machine. At that point, your program is stopped - it doesn't keep running.
If you choose an instance of VS, it will be launched, and will be stopped on the line with Debugger.Launch(), as if you hit a breakpoint there.
So there is really no reason for the while() loop. You could just call Debugger.Launch() whenever you want to stop the program to look at something.
But the utility of Debugger.Launch() is questionable. You can much more easily use breakpoints, and with breakpoints there is no danger of accidentally leaving it in the finished product.

WPF: program.exe doesn't exit "the process cannot access the file.. used by another process"

I've worked on quite a few WPF solutions, and this is the first time i am seeing this problem.
Today it started happening intermittently. where after closing my WPF window, the .exe is still running under visual studio.
so i have to kill my program.exe manually in order to compile again.
Initially i thought because i overrode application start/exit/exception .. but i commented all that out, and it is still happening.
In fact, i see multiple instances of my program.exe in process explorer!
Can't figure out what is causing my exe not to exit. Is there any explicit dipose logic i can add in applicaton exit event to ensure it really exits?
My application consists of single window, and multiple user controls as views.
update
if i open in debug mode. and close the main WPF window, my visual studio does not stop debugging. however call stack window is empty.

You can use the Application.Exit event to log when your application shuts down.
Alternatively, you can attach the debugger to your running instance (even if it wasn't started in the debugger) then pause it to see where it's at. Make sure to look at the Threads tool window, as you may pause outside the UI thread.

This should take care of it, though its probably better to try to figure out the underlying issue.
System.Diagnostics.Process.GetCurrentProcess().Kill();