We Keep Coding

Debugging: get path of execution

I was wondering if there is any way to return the path that Visual Studio takes when running through a program. For example, without setting breakpoints, is it possible to know exactly what happens when I click a button on a web app I created? Like if I clicked a button that had an action, is there some kind of info that Visual Studio can spit out that tells me what happened? (which functions in which files were used, etc. Essentially the "code path").
To add on to my question, I'd like to use something like this to help debug an issue. I want to know exactly what is happening when I perform some kind of action (button click in my example). If I know every "code path" I can better address the issue I'm having.

If I understand correctly your question, you're looking for Environment.StackTrace
The StackTrace property lists method calls in reverse chronological order, that is, the most recent method call is described first, and one line of stack trace information is listed for each method call on the stack. However, the StackTrace property might not report as many method calls as expected due to code transformations that occur during optimization.
Something else you can do is adding debug log entries to know what's is going on. It may be more useful since you could add extra custom data.
Not sure if you already have a log framework on your project. If you don't have any log4net could be a good option

Converting my comment to an answer so there is an answer that addresses the original question:
Use a performance profiler, which is designed to observe execution paths (typically to help you find bottlenecks, etc., but it will work fine for your purposes too). A good performance profiler will let you dig down and see, for any method, what methods it calls, how frequently, etc.

You can print out a call stack results to the output window in Visual Studio. You will still need to use breakpoints but the ones that doesn't stop the application. To do that:
Find the place in your code when you would like to get the stack printed out. For instance at the end of button clicked handler.
Place a break point there.
Right click the breakpoint. From the context menu select "When Hit..." option.
In the window that will show up select "Print a message:" checkbox. It will enable a textbox. In the textbox type in: $CALLSTACK.
Check the "Continue execution" checkbox if you don't want to stop the execution while printing the results.
I don't remember if the "When Hit..." option is available in the Express edition of Visual Studio.
There are also some other data you can print out without breaking execution, e.g.: previous function, process id, etc. The details are actually available in the "When Hit..." window.

Console.Write() - Where does this write to, and how to get written data back (in a Web Page)

I've seen it in many code samples, tutorials and other people's code that I've worked with. I've never really understood (or even learned) why people use Console.Write(exception.Message);.
The only reason I can think of is to log the exception for later investigation. So, I thought I'd give it a try, since I have some spare time on my hands, and have tried to find some specific info regarding my questions, but couldn't find it.
If I use Console.Write(exception.Message); in an asp.net webpage, where exactly does this go? Where is the "Console" in a web app/site?
And, how do you "see" what you've previously written to the Console?

In Visual studio, for winforms and WPF application it prints to Output window
For ASP.Net use System.Diagnostics.Debug.WriteLine() to print to output window
To open the Output window, on the View menu, click Output.
You may want to see: Where does Console.WriteLine go in ASP.NET?

saveFileDialog Long Wait on "Okay" Confirmation

I'm writing in Visual Studio 2008 using C# (if that makes a difference) and I have the following snippet of code:
if(saveFileDialog1.ShowDialog() == DialogResult.OK)
{
//Write Stuff to File Here
}
For a while I thought my code that wrote the file was taking forever, however upon debugging it seems to take forever (5 to 10 seconds) just to step between the "if" statement and the first bracket of first code within the "if".
Is there anything I'm doing wrong? Is there any difference between creating the saveFileDialog object in the UI versus creating it on the fly (through code)? Would it make a difference if there is no "else" statement?
Any thoughts or ideas would be greatly appreciated!

This is not unusual, on many machines a ton of DLLs get loaded into your process when you use that dialog. You can see them getting loaded by using Project + Properties, Debug tab, tick the "Enable unmanaged code debugging" checkbox. The Output window shows a trace of every DLL that worms its way into your program.
These are shell extensions, customizations for Explorer. The dialog you use is a shell dialog, you surely recognize the similarity with regular Explorer views. Things like icons and context menus behave the same. Having a lot of shell extensions installed is common on developer's machines, more so than user machines. There are a lot of them out there, offering such conveniences as integrating whatever tool you like to use with Explorer itself.
Debugging the problem isn't that easy, you won't have the actual source code for these extensions. You might get a hint about the troublemaker from the trace in the Output window. If there's a lengthy pause after one particular DLL then odds are good that this DLL is the source of the problem. Nothing really solid though.
The better approach is to use SysInternals' AutoRuns utility. It shows you exactly what shell extensions are installed and allows you to disable them by simply clicking a checkbox. Start disabling anything that doesn't have a Microsoft copyright and stuff you could live without. Logout + Login required to make the changes effective.

Debugging C# applications

I´m coming from a PHP background where my debugging "tools" are basically echo, var_dump and exit. While I know the importance of debugging, I never tried to use/learn a debugging tool.
Now I´m learning C# and I think I can´t really program without an extensive knowledge of this area.
So my question is: where can I learn what is and how to do debugging? I know what is a breakpoint (conceptually), but how to use it? How to use Step into and Step over? Basic things like that.
As a related question, there is anything like var_dump in C# (Visual Studio), where I can inspect any object.
I find very difficult and painful to do a foreach for every array/list to see the contents, specially now that I´m still learning the language.

Microsoft has an extensive guide on C# debugging in Visual Studio that might be helpful. VS has a lot of powerful debugging functionality; for example, rather than doing a foreach to see the contents of an array as you were describing, you could set a breakpoint (pausing the execution of the program) and select the variable you wish to see the contents of (array or list or whatever) and see what it contains, without having to write any extra code. Step Into and Step Over can be used to continue execution of the program but only incrementally so that you can continue to see how variables change, where the flow of execution currently is, etc.

This has been covered earlier on StackOverflow:
Best Visual Studio 2008 Debugging Tutorial?

So, your compiled applications can be run in a "debug" mode from which visual studio can monitor the internal workings of the application and even control it.
A break point can be placed just about anywhere in your code by clicking to the far left of the line (kinda in the margin of the visual studio text editor). When that line of code has been reached, the visual studio debugger will actually pause the execution of your program and bring you back to the editor where you can literally hover over a variable or object or whatever and see everything about it.
There is also a "Locals" window available that will give you the break down of all of your locally scoped items - this should pop up by default at the bottom of your screen when debugging.
In debug mode you can navigate the execution of your code line-by-line
F10 will continue with the next line of code.
F11 will attempt to drill down into what ever functions are on the current line of code
Ctrl-D will bring up a "Quick Watch" window giving you all information about the currently selected variable/object.
Once you are in debug mode there are tons of things you can do - in some cases you can even edit the code as you go.
The easiest way to get into debug mode is to use the little "play" button up at the top of visual studio - and when a break point is reached it will enter debug mode and highlight the currently executing line of code.
You can also hit F10 from the editor and your application will be started and paused on the very first line of code.
By comparison, in PHP, you had to actually write "debugging code" into your application - using Visual Studio you can actually monitor the execution of your code without adding a thing to your existing code.
I hope that gets you started.
You might want to also read up on your IDE a bit to. There is a metric ton of stuff in visual studio that will help you navigate your code in ways you never imagined in most PHP editors.

If you've already downloaded Microsoft Visual Studio, you'd might want to check out the Visual C# Express Library available for free over at: http://msdn.com/express/
It's located down the bottom of the page and is very useful. It contains pretty much every answer you might be looking for as a beginner to the C# Language. ...Welcome to C#, my friend :-D

Is there a way to *completely* disable Edit and Continue?

I was wondering if there was a way to completely lock my code while debugging it within Visual Studio 2008. The code documents lock automatically when running as 64 bit applications, which I greatly prefer; however, I do most of my coding making add-ins for Excel, which is 32 bit. The result is that even though I target 'AnyCPU', the VS host knows that it is running within a 32 bit process and, therefore, the source code is not locked while the code is running hosted in Visual Studio.
I can turn off Edit and Continue by going to Tools > Options > Debugging > Edit and Continue, and then unchecking the 'Enabled Edit and Continue' check box. This does not completely lock the code, however. This does prevent any edits in the code from being executed in the current run, but it does not prevent mouse clicks or keystrokes from actually changing the code.
Again, when working with 64 bit applications this does not occur -- the code is completely locked. I greatly prefer the code to be completely locked for at least a couple of reasons:
I can accidentally hit a key or the like while debugging, which I definitely do not want to do. It's rare, but it is an issue.
Many of my automated tests drive the user interface via SendKeys. When stepping through such a test using the debugger, however, I can sometimes forget that some of the aspects involve SendKeys, which means that keystrokes wind up getting sent to the Visual Studio IDE instead of Excel.
In issue #2, above, the unit test fails, which is fine -- my bad -- but having all the keystrokes sent to the code module and destroying my code is completely unacceptable.
Does anyone have any ideas here? Can one completely lock the code when running hosted in Visual Studio while compiled against a 32 bit CPU?
Some related posts on this issue, but none of which directly address this:
How to: Enable and Disable Edit and Continue
“Changes to 64-bit applications are not allowed” when debugging in Visual Studio 2008
How do I enable file editing in Visual Studio’s debug mode?
How does “Edit and continue” work in Visual Studio?
Can we edit our code while running the application
Editing C# while debugging
Thanks in advance for any help or ideas...
Mike

Here is a trick I use under Visual Studio 2005 (don't have a chance to test under Visual Studio 2008, but it should work):
Open the executable assembly's properties
Go to the Debug tab
Check the Enable unmanaged code debugging checkbox
The code documents should stay locked, even when a breakpoint is hit, and any attempt to change it should trigger a popup saying "Changes are not allowed when unmanaged debugging is enabled".

Hey there - sorry I can't help you with completely locking your code - I have the opposite desire: to completely UNLOCK it during debug, but I can help you with your second issue.
I suggest that you consider checking the active window before sending any keys and if the active window is other than your target site, pause the execution of your test until focus is returned that that window.
I know it's not the solution you want, but it probably wouldn't hurt to prevent other similar issues.
Best of luck!
Adam

Here is the best I could come up with. It works, but there are some steps you may not want to take.
Essentially, the technique is to set the files of your project to Read-Only when you run the application, and then set them back to writable once your application ends.
However, in VS2k8, by default, setting a file to Read-Only still allows you to edit the file. You need to first turn off the setting "Allow editing of read-only files..." in Tools > Options > Environment > Documents.
Second, you need to add the following key to the registry as a DWORD and set its value to 1:
HKCU\Sofware\Microsoft\Visual Studio\9.0\Source Control\UncontrolledInMemoryEditDialogSuppressed
This still won't work completely. What you then have to do is set your Source Control for that project to Visual Source Safe. (<-- this is the step I'm assuming you won't like.)
Then restart VS2k8.
At this point if you set one of your files to read-only, you will see that Visual Studio will not let you edit this file at all. When you try, it plays your computer's exception music.
Now, to make your files read-only when you run the app, set a post-build process to do this. That's easy.
Harder, is to set them back to writable once your app finishes running. The simplest solution is probably a batch file shortcut.