I have a maddening problem that I feel may be a gremlin that won't be slain.
In a C# application that I've moved from VS2005 to VS2010, I have a application setting that is a Boolean, set to default of False in the settings screen in the IDE.
However, when I fire up the program, even setting a breakpoint in void Main, this setting is set to True. Nowhere do I set this to True in code, and the variable hasn't even been accessed before this breakpoint, which is even before I launch the main application form.
What's MORE, when I run this same project in VS2005, and set the breakpoint in the same exact place, it is False, which is correct.
I've restarted VS2010, tried setting the value manually, which of course works. I even restarted my workstation, all to no avail. I hate stuff like this...
Thanks.
Ok, I do NOT like answering my own stuff - try not to, but just stumbled across the solution. As dumb as it sounds, I had to delete the setting in the IDE, and re-add it, after which it behaves properly.
I would love to hear someone familiar enough with the 'guts' of VS explain WHY this happened, but at any rate, that's what I had to do to fix it.
Related
We have some library projects with a VPI extension. Defined in the DPR with library at start and {$E vpi} at end (Options > output settings > Application > Target file extension: vpi).
library appname;
uses
//...
{$E vpi}
Problem: When I run a debug in a VPI project it works only once. After any change it won't hit the break again. Now showing a "green" breakpoint when you run the app. The only way to get it back to work is by closing and open the IDE.
My Co-worker asked me if I have this problem last year, which I didn't. In his machine "when you change anything in your source, even a space in a comment, the break points won't work till you close and open the IDE again" he said.
We've compared lots of config from the IDE and we didn't find anything.
Now for some "no reason" my computer also stopped working with the debug.
I have looked into this topic "Delphi: why breakpoints from time to time are not usable (green highlighted line on IDE)?" with no luck.
I've tried the Clear unit Cache, un-check and check again the debug info, include TD32, include remote debug, uncheck optimization.
I've asked to other teams and they said that some machines works others don't. But they also don't know why.
Maybe someone here have another trick that may help.
I know that sound like a stupid question, and we can find many answer on google.
However, i've been trying for one hour and it still not working.
The question is prety simple, i'm coding on visual studio code on Mac OS.
And i want to instert tab when i press tab, and not 4 spaces.
It it supposes to be very simple :
Go on "code"->"preferences"->"users stting"
And add :
// Insert spaces when pressing Tab.
"editor.insertSpaces": false
Into : settings.json
However i have no clue why, but this is not working.
(I've save it, close visual, reboot mac, still not working)
Does anyone has any clues to help me?
Thanks a lot.
(I've save it, close visual, reboot mac, still not working)
--> One thing is missing - did you try it with a completely new file? ;)
I just tried it, had the same issue and almost thought it is a bug, but it seems to be expected behavior as there is another setting editor.detectIndentation which is true by default.
If the indentation is detected then the detected value takes precedence over your defined setting. At first this seemed odd as others also reported in a GitHub issue. But the analogy with CR/CRLF in this issue makes sense.
So as a quick fix you could set editor.detectIndentation to false or convert your existing indentation to tabs so that the next time you open the file the proper detection is done.
I'm running Visual Studio 2010 with SP1, as well as R# 5.1, and a few other extensions (like PowerCommands and Productivity Power Tools). Somewhere along the lines, my debugging got super slow. If I use the F10/F11 keys to step, VS hangs for a bit and then steps. If I use the toolbar buttons for stepping, it's snappy as expected.
Any idea what's up with my shortcut keys?
I had exactly the same problem - extremely slow debugging with keyboard (F10 for example). Some symptoms:
if I click Step Into on toolbar, then everything works normal,
the lag during debugging is present not only in Visual Studio but anywhere (notepad, browser,...),
if I set any other browser as default browser in Visual Studio (I tried Firefox), then it works OK,
if I disable third-party browser extensions in IE, then it works OK,
if I enable third-party browser extensions and disable LastPass, then the problem is gone and debugging with keyboard is fast again!
So, try to disable LastPass extension if you have it or all extensions and try it.
Edit1 - somebody allready posted this on LastPass forum: http://forums.lastpass.com/viewtopic.php?f=12&t=61029
Edit2 - and here on SO also :) https://stackoverflow.com/a/8186670/1110039
I've found a deeper explanation for this problem.
I had this problem, with the symptoms user1110039 described BUT I haven't installed LastPass toolbar. And my default browser is Firefox.
Well, my application uses SetWindowsHookEx() function for setting a system wide shortcut. Which happens to be the reason for blocking F10/F11 debug keys (only in Windows 7 64 bits) It doesn't happen under 32 bits.
I've just removed the hook from the debug build and it works ok. I reckon the problem with LastPass is some system wide hook in the code of the extension.
I had exactly the same problem.
The problem was solved by closing the Watch window.
Try debugging with Firefox or Chrome. There must be something about the interaction with IE that is causing this behavior.
Disable "show threads in source" worked for me!
Calling DirectInput's Acquire() function on a keyboard device is what caused the slowdown for me. This is potentially related to the SetWindowsHookEx() caused slowdown - ie. that might be using DirectInput.
It's really odd that the keyboard stepping is slow while the toolbar buttons are not. Typically whenever I hear about a slow stepping experience my recommendation is to disable automatic property and ToString evaluation as this is the most likely cause
Tools -> Options
Debugger -> Uncheck "Enable property and .ToString evaluation"
I'm not very hopeful that will fix this instance. It sounds like a problem with a misbehaving extension that processes keyboard input. Your best bet is to disable the extensions one by one and see which one fixes the problem. I would do it in the following order
Productivity Power Tools
Power Commands
R#
Make sure you've installed Service Pack 1. I believe they fixed at least one significant performance problem in the debugger.
I experienced that very slow step by step debugging too, and fixed it by closing the threads window.
(Making a note here on an old thread, so it can be found in a web search.)
I normally leave the ==Disassembly== window open during debugging (I have a big screen.) I just discovered that single-stepping in the debugger can be speeded up by 50% if I hide that window too. The -tab- for it can exist and be handy - makes no difference - but the window itself shouldn't be showing. Ahah.
Have followed all the other suggestions and more from elsewhere, single-stepping is now about 8 times faster overall. (About 2.5 steps per second now.) Woo-hoo! Thank you all.
(I don't understand how they can write such slow UI code... I have a CPU here that's running at two billion cycles per second... that works out to about 400 million instructions per single step. Seems like Microsoft code could be a -little- faster... but then, I've never had the pleasure of using .NET etc.)
I tried all the suggestion and finally found that When I uninstalled VS2005, this issue got resolved. Note that in that machine VS2005
I was having this problem in my new job, where we use Visual Studio 2008 SP1. (Yes, I know, I know). Long delay on step with flickering hourglass. I always use F10, I don't even think about it, there's no way I could tolerate changing to the mouse or waiting multiple seconds for a simple step command.
I read through all the solutions provided here and elsewhere on the net with no joy.
Finally found the issue - I had set up my default language for the IDE as C#. It turns out the project I'm working on actually uses VB.NET, and when I set the default language to VB.NET (via Tools - Import and Export Settings) the debugger got so fast that I couldn't keep up with it and accidentally pressed F5 on the breakpoint I want to examine.
I hope this helps someone else.
In the end, the disabling of Last Pass in my browser (IE) was what solved this problem for me, but along the way I learned a lot of other things that could have just as easily been the cause. A variety of other valid answers to this question (Some in the various answers on this page) are validated and explained here:
http://blogs.msdn.com/b/visualstudioalm/archive/2015/03/03/make-debugging-faster-with-visual-studio.aspx
This article explained that this F10 slowdown can be from having various diagnostic windows and toolbars open, Symbol loading issues, etc. and also explained what to do about debug slowdowns in general. It was an eye opening education that I think will continue to help me in the future should the F10 slowdown rear it's head again.
In my case it was the Call Stack window (Visual Studio 15.9.13) that caused the lag!
Even when I stepped over a very simple line like ++i; it took around 1-2 seconds until the debugger stepped over to the next line. Closing the Call Stack window or hiding it fixed the lag for me immediately.
I am using a dedicated test SL web application that hosts SL object I am debugging.
I am debugging using basic F5 and use browser Google Chrome. Sometimes a bug happens, how I reproduce it.
I was running build->debug like 100 times already, but then I made a mistake that caused StackOverflowException and happened in main page constructor and afterwards when I rebuild and hit F5 it says no symbols have been loaded. Note that NOTHING has changed , I use the same 2 buttons combinations rebuild solution-> start debugging.
In order for debug to continue to attach I need to close XAML main page , open it again (in visual stuido) and hit rebuild ->f5 again, afterwards it works fine. (found this solution after SOME time)
I am not sure whats bugged but it appears to be a bug somewhere in SL to me.
Question is - whats going on maybe someone can explain.
This sounds more like Chrome's isolation mode for plug-ins. Generally speaking it's best to manually attach to the Chrome process that is running Silverlight (which isn't always one VS attaches to when pressing F5).
Actually error was super simple, I wasn't understanding how "exactly" xap works, it was a little more magical to me than it is. I just needed to rebuild & clear cache in browser ( chrome in this case) to attach successfully. For some reason I thought that local version doesn't require clear cache call.
Actually chrome is pretty bad to debug silverlight so I recommend IE for this sole purpose, sometimes debugger simply fails to attach to chrome, in that case you usually need to do this by attach to process - choose chrome with silverlight name there.
In Visual Studio 2008, after debugging about 1-2 minutes, when I press F10 (Step Over), the debugger hangs and Visual Studio freezes for 5-10 seconds and then go to the next line. Then whatever I do (F10, F5, F11, etc), the debugger continues the execution as if i pressed F5 and all my forms that I was debugging close. I always have to restart the application.
It is very hard to reproduce and it does not occurs every time I want to debug something. Does anyone has a solution ?
EDIT : I've managed to reproduce my problem with the following code :
static void Main(string[] args)
{
XElement e = new XElement("root");
Test(e, 0);
}
static void Test(XElement parentElement, int i)
{
if (i < 1000)
{
XElement element = new XElement("element");
parentElement.Add(element);
Test(element, ++i);
}
}
You need to put a conditional breakpoint on the line "XElement element = new XElement("element");" with the condition "i == 999". Then start the program, wait 2-3 seconds and put normal breakpoint on the line "parentElement.Add(element);". Now VisualStudio freezes and it is impossible to debug. In a WinForm application, it closes all the forms that are open after pressing F10.
But I found that if I disable the debug option "Call string conversion function on objects in variables windows" in "Tools -> Options -> Debugging", I can debug. It is slow but at least VisualStudio doesn't freeze. Does anyone know why it is doing this? Because I don't want to disable this option, it's really annoying to debug without it.
I also noticed that if I only put a breakpoint at the end of the main method, the code runs really fast compare to having a conditional breakpoint in the recursive method.
Try deleting the solution user options file (.suo) where the debug/breakpoint information is stored. You will lose all solution user settings, such as breakpoint locations. When you have "funny" debugging incidents, this is the first thing to try because this file can get corrupted.
If this does not solve the problem, then you have something else going on, such as threading issues, excessive memory fragmentation, garbage collection issues, dispose/finalize issues, and so on.
I found the answer to this question on another Stackoverflow thread. There's a MS hotfix for this issue.
I've found that I get slowdowns like this whenever I have added remote unc shares that don't exist to the list of symbol directories.
Try going to Tools -> Options -> Debugging -> Symbols and make sure that all of the directories in that list actually exist.
I have no idea how that would cause your program to continue after that point however.
Not sure I've ever run into this, but if I were you, if you haven't, delete your bin folder, and rebuild your project. Then run a clean solution to be safe. Sometimes, funky things can happen with your PDB's getting out of date -- so you need to clear them out.
Also, if your calling outside assemblies, remove them and reattach them to make sure you have the most up-to-date assemblies.
I have had this exact same problem just as you described. The MS Hotfix addressed the issue and now I install this hotfix whenever I do a fresh 2008 VS install.
Please download the fix from this link
http://support2.microsoft.com/hotfix/KBHotfix.aspx?kbnum=957912
I know this is an old thread but this occurred when debugging an Excel add-in in my case.
Problem was that my breakpoint was in a background thread and in my watch window I had an old check on the ActiveWorkbook in Excel. That call just like many others should only occur on Excel's main thread.
Once I removed that watch, it debugged just fine again.