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.
Related
Im looking the name definition of this process so I can learn it properly. When I debug code in VS ill hover over a var before breakpoint to see what data is held in it and this window pops up which allows you to see methods and properties, there is usually a base item in it too. Is this called intellisense or something else?
I dont understand the difference between a lot of the items an how you find the thing (function?) you want - especially when things seem to be many levels deep in this window.
Thanks C
The window that pops-up is called a DataTip, the parts of a DataTip that let you examine the representation of a value are called Visualizers.
See Debugger Basics.
I did some research on this before asking the question and since I might be asking it incorrectly, I might not have done the right searches here first.
What I am trying to accomplish is when I start to debug or run an application in Visual Studio, is to have the IDE show me what methods are executing when I do something in the GUI/application.
For instance if I click a button in the GUI labelled "Search", I want to see the chain of events/methods that execute for this process. This I am not sure of. I hope I have asked the question correctly. Thank you for your time.
Have a try with IntelliTrace.
Make sure IntelliTrace is enabled and call information is selected;
Launch your GUI application, and perform what action you want;
In IntelliTrace window, click Break All. If IntelliTrace window is not displayed, click Debug -> Windows -> IntelliTrace Event;
Expand the event you are interested, for example, 'Clicked Search', and click Call View link;
You can see call stack you are interested.
There are two ways to approach this:
If you have no idea where the code you are looking for is, then simply start your program with a Profiler such as JetBrains dotTrace. Then, get ready to push the button, click "Start Profiling", click the button, and then as soon as the operation is finished, click "Get Snapshot". Now, use dotTrace's Call Tree to see which methods called which. I use this technique all the time for just this purpose!
In this view, you can use the arrows key to navigate the method-calls tree.
If you have a general idea of which class[/es] get invoked when you hit the button on the GUI, but don't know exactly which methods are called, you can use OzCode's "Add Breakpoint to Every Method" on a class, so that even if you don't know the exact method that's about to be called, whenever the class is accessed, you'll break into the debugger and be able to explore.
Due Diligence Disclaimer: I am a co-creator of OzCode.
You can use the Runtime Flow tool (commercial, developed by me) to see the chain of events/methods in a .NET application for GUI actions.
I want to completely remove "error list" from visual studio 2008, not disable it i want it gone. It annoys me to no end popping up endlessly, i guess i must be "doing it wrong" but w/e i just want to use VS without being alerted every other keystroke about some warning.
I've tried editing many different fields in the options (tools -> options) it has only slightly decreased the frequency of the error list popping up. I have also deselected errors, warnings, and Messages. and it pops up with nothing to display. unpinning it doesn't help either.
also upgrading to VS 2010 is not an option at this point.
Im looking for a solution something like the following: remove a dll or config file responsible for this
Also I still want the inline validation (the little squiggly marks, etc), but
the error list window annoys me.
I think this is probably exactly what you're wanting:
http://blogs.msdn.com/b/zainnab/archive/2010/05/16/hide-or-show-error-list-when-the-build-finishes-with-errors-vstiptool0022.aspx
You can change this behavior by going to Tools -> Options -> Projects
and Solutions -> General and deselecting the "Always show Error List
if build finishes with errors".
I'm guessing this will work with ASP.Net as well, since that's building on the fly.
I am using Visual Studio 2017, and I also have to cope with the useless, impossible-to-disable, annoyingly-in-your-face, and outright disturbing "Error List" window.
So, here is what I did:
Undock the "Error List" window to make it free-floating.
Resize it to the smallest size possible.
Move it out to some remote area of the screen where it is not so annoying.
And voila, problem solved ! (*1)
*1 Well, problem mostly solved. It will be completely solved when I abandon this dinosaur of an IDE.
My 'Error List' was constantly displaying also (VS2012). I also hate it.
I turned it off years ago, but today it just started appearing.
It was being caused a unreadable packages.config file. For some reason that reports it's fail state through the yukky 'Error List'.
Fixing the packages.config file stopped the 'Error List' from appearing.
for VS2017, select the "Build only" value from the drop down list in Error tab. Refer to the image below:
Hope this helps!
On Error tab, you have Errors / Warnings / Info buttons. Click on Errors button (de-press).
hope it helps.
I suggest turning off inline validation.
Yes, I know that you still want it. But, seriously, how important is it? It's trying to validate code that is half-written. How valuable can that be?
First of all, as-you're-typing code validation is distracting. It makes it harder to focus on the problem you are trying to solve. For example, writing a function with a non-void return will display the "not all code paths return a value" error continually until you get to the end of the function. In the meantime, the editor is telling you that there is a problem. I am sure that people learn to ignore these things over time (I have never kept the feature on for more than a few minutes after a new VS installation, so I don't know), but if you are actively ignoring something, then what good is it?
Second of all, any good that the validation would be capable of is unnecessary, because those errors will be brought to your attention at compile-time anyway. Having an uninitialized variable pointed out to you while you are thinking through the algorithm does not improve the quality of the code at all verses having it pointed out when you try to run the program. The variable is still going to be initialized either way. And there is an extremely high likelyhood that you are going to fix the problem before trying to run the code anyway.
So I just don't see the point of it. I suggest turning it off, and then your problem goes away.
UPDATE
As pointed out by #Charlie Kilian, there is a flaw in VS in which .aspx files are not validated at all, unless the "Show live semantic errors" option is enabled for C#, rather than validating those pages at compile-time as would be expected.
Therefore, editing aspx files will require turning this option back on for validation.
I guess I'll be going back-and-forth with it from now on. I hope they fix this in future versions of VS.
I still think that doing a semantic analysis and error-reporting on code that is actively being edited is a fool's errand. (Of course, I have also been known to write entire programs in notepad, just to see if I could get it to compile and run correctly the very first time without the crutch of Intellisense. It feels pretty awesome when it works.)
Selected answer is incorrect because unchecking "Always show Error List if build finishes with errors" does nothing to stop the dreaded Error List window from popping up on other errors, even if you change it to show only Build errors.
11 years later in Visual Studio 2022 it is still impossible to disable Error List window.
The only correct answer to the question "Completely remove error list from visual studio" is to uninstall Visual Studio itself which, thankfully, also removes Error List window.
Either that, or we should all get used to it, because Developer Gods from Microsoft want everyone to work in absolutely the same way as they do. Every workflow that differs from their own is wrong, and every thought that doesn't align with their grand vision is blasphemy.
It is One Microsoft Way or the highway.
I am currently creating a customer application for a local company. I have a datagridview linked to the customers table, and I am trying to link it up so that updates, inserts and deletions are handled correctly. I am very new to c# so I am starting with the basics (like about 2 days ago I knew nothing - I know vb.net, Java and several other languages though..).
Anywho from what I understand anything output through Debug.WriteLine should only appear when in debug mode (common sense really) but anything output through Concole.WriteLine should appear whether or not in debug mode. However I have checked the immediate and output windows and nothing is being output when in normal mode. Does anyone have any idea why this is??
Edit: I have event handlers for clicking a cell - it should output CellClicked and set the gridview to invisible when a cell is clicked. The latter works whichever mode I am in, but CellClicked is only output in debug mode. I am using Console.WriteLine("CellClicked").
Edit: Seems I may have solved it - I just set the output to Console Application in the project settings pages. It now opens a command line window as well as a windows form, but I can change the output back again when I compile for distribution. Thanks for the help.
Console.WriteLine() outputs to the console window in the case of a console app only.
You are probably looking for Trace.WriteLine().
Getting the output of Console.Write/Line() written to the Visual Studio Output window is a feature of the Visual Studio Hosting process. Project + Properties, Debug tab. This will not work if you run your app without a debugger, the hosting process isn't being used.
Using Console.WriteLine for debugging isn't the greatest solution. That code will still run in your Release build and take time formatting the output string. And prevent the JIT optimizer from doing a good job generating the most efficient machine code. Output will fall in the bit bucket, nothing to actually write it to.
And it is unnecessary, the debugger gives you much better tools to find out what is going on in your program. Take some time to familiarize yourself with its capabilities. If you want to find out if an event handler runs, just set a breakpoint. Such a breakpoint can even trace output without actually breaking. Right-click the red dot, click "When hit" and use the "Print message" option.
I think you'll like the tracing infrastructure a lot better than Console.WriteLine. Tracing gives you many different options for where the trace messages can go, as well as being able to turn them on or off. You can also set different levels of tracing output so that you can adjust how much logging actually gets done. The built in tracing in .NET is very flexible, and is well worth the investment to learn.
Here are a couple of references to help you get started:
http://msdn.microsoft.com/en-us/library/ms228993.aspx
http://msdn.microsoft.com/en-us/library/ms228984.aspx
http://www.code-magazine.com/Article.aspx?quickid=0409081
HTH!
Chris
You could go to Tools | Options | Look for Debugging, General, Choose the Redirect all Output Window text to the immediate window, or try to log the console-intended output to a file and view it there instead.
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