In a particular project I recently started the debugger started acting funny. When I'm debugging and it is paused at a breakpoint, Data Tips don't show up, some of the variable values don't show up in the Locals and Autos windows, and there are some strangely named variables in the Locals window (the ones starting with "CS". The other ones are my variables):
I can't for the life of me figure out what is different about this project than my other ones. I'm running Visual Studio 2013 in Windows 8.1. The project is a Windows Phone 8 project, with the only added references being Fody, PropertyChanged.Fody, HttpClient et alius, and JSON.net.
Any help would be appreciated.
I had the same problem here (also using windows 8.1 and VS 2013)
To fix it you need to open in VS Tools | Options | Debugger | General and enable the flag [Use Managed Compatibility Mode], which essentially gives you the VS 2012 function evaluation behavior.
Reference:
http://weblog.west-wind.com/posts/2013/Nov/21/Visual-Studio-2013-Could-not-evaluate-Expression-Debugger-Abnormality
[Build] => [Clean solution] has fixed this issue for me when nothing else has worked including emptying the symbol cache.
Try TOOLS->OPTIONS->DEBUGGING->SYMBOLS and hit button Empty Symbol Cache.
This did the trick for me (VS 15 on WIN 10):
Debug --> Options --> On General tab check Use legacy C# and VB expression evaluators.
I tried above all suggestions but none of them worked for me. Following resolved my issue -You can try by resetting VS settings. Tools-> Import and Export Settings -> Reset All Settings and then press Next.
If you're referring to the 'locals', you can reopen it (while debugging) by going into Debugging -> Windows
It's only accessible during a debugging session.
I was facing some weird issue on my Visual Studio 2017 (Community) installation while debugging which is how I reached this thread. I'm posting my findings in case it helps someone. Any of the already posted answer's didn't help me.
The thing was whenever I hover my mouse over a variable during a debugging session then I can see its value in tool tip but it was working only for primitive data types e.g. int, char, string etc. In case the target variable was an object or an array I will not see any way to expand the object to see its property values, internal members and things like that as shown in the screenshot below for variable A which is an array:
So to overcome this problem for non-primitive data type variables (objects and arrays), every time I will select the variable and press Ctrl + F9 to open the quick watch window and see the object members there but gradually it was becoming irritating and time consuming.
While trying various solutions present in this thread by mistake I clicked on the empty area beside the variable name in the tool tip window and whoaaa it was all there :)
In general in that empty area on the left hand side of the tool tip window, there is a plus (+) sign which we click to expand the object details but it was just that the plus (+) sign was invisible. I reverted all the options I had applied as per the suggestions mentioned in this thread and it was still working.
So I concluded it was just a curious case of invisible plus sign. Now I've a normal debugging life :P
Root cause of the problem could be Visual Studio 2017 Community (Version 15.3.0) or Windows 7 which is my host operating system(OS). As far as display drivers are concerned then that's not the case for sure as I had built this laptop more than a year back and it had been all good for all other applications.
Related
There usually is a variable list at the bottom of the screen that helps me follow the value of different variables in my app while using the f11 'step into' function, but since I updated to web developer 2012 I can't seem to find this list. Was it removed? or is there a way to open it? thanks!
Set a break point in the project, start debugging your application, once you hit the break point, go to Visual web developer, Under Deubg-> Windows, see if you find Locals option. That will show the local variables during debugging.
I have an MVC application which uses a silverlight control.
Somewhere along the line something is happening in the silverlight cs code that isn't right. I've inserted break points in the CS silverlight code to get a better idea of what's happening, but for some reason I just can't step through the code.
I know code is being hit, but it's just not showing me in the debugger.
I thought it might be because I was using Chrome as the default browser but I changed this to Internet Explorer and still no joy.
I realize this is a very vague question, but has anyone else experience anything similar, and if so, how did you get around it?
Any help would be appreciated,
Thanks.
Be sure to set the Silverlight Debugging checkbox on the project properties Web tab
If Chrome is your default browser and your breakpoint tooltip shows this message:
"The breakpoint will not currently be hit. No symbols have been loaded for this document"
... then it is possible the debugger attached to the wrong Chrome process at debug startup. A work-around is:
Start debugging your Silverlight app. Your app should be running in Chrome.
From the Debug menu, select Attach to Process...
Scroll through the available processes and locate the chrome.exe process that shows the type as 'Silverlight x86'.
Select that process and click Attach.
I had firefox as my default browser and nothing was being hit(I even tried attaching to a process). What finally worked for me was setting IE as the default.
Silverlight break points are now being hit for me! :)
Right Click on Web.UI project in solution. go to Web , check Debuggers --> Silverlight save and Debug..
Make sure you have silverlight developer installed.
Your code may be part of a class marked with the System.Diagnostics.DebuggerStepThroughAttribute. This happens with auto generated classes (like with Add Service Reference). If you are extending a partial class, other parts of the class definition may have that attribute.
Try unckecking the Options / Debugging / General / Enable Just My Code checkbox.
Otherwise put your mouse over the red dot in the source code window, which becomes an empty circle if the debugger disabled it, a tooltip will give you additional information.
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´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
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.