I keep having intermittent issues with visual studio 2010: I'm working on a rather large solution (200+ projects), so the whole solution takes a long time to build even with a little change.
I often need to debug processes on remote machines.
What I noticed is that visual studio would often appear hung on detach or terminate remote process. On closer examination, it appears that immediately after debugger disconnects, VS will start to build solution, and it is not possible to cancel the build by pressing Ctrl+Break, in fact no menus work at all until the build finishes or fails, and with large solution it takes a long time. One way I found which would fix this issue is killing the MSBuild.exe processes, spawned by VS, which would fail the build.
Have anyone seen this behavior? Is there any fix? Very annoying
EDIT: This is how the process explorer looks after disconnect from debugger: http://vvcap.net/db/oz1NMoyXnWWlQp8mWaRY.htp
This would happen when you edit code while a breakpoint is active. After the debugging session ends, VS automatically rebuilds the solution to incorporate the changes into the binaries, not just in memory. This does tend to make VS a bit catatonic, I think it tries to prevent you from doing anything that would interrupt that operation. This normally doesn't take more than a couple of seconds but I have no idea what might happen in such a large solution. Disabling E+C is probably not one of the workarounds you'd contemplate if you are used to being able to edit code while debugging.
Having solutions with 200 projects does tend to test the limits of endurance. Do try to whittle it down to a core set of projects, chucking out the ones that shouldn't change because doing so would break too much code in higher layers. Or just create another solution and include only the projects you want to test. It doesn't otherwise affect the debugging session, you can still debug code from such projects as normal. Without E+C of course.
Such amount of projects in a solution file can take a LOT of time to build. I can't (myself) imagine) the worries before pressing ctrl+b (know that takes 30 seconds of my working hours).
I would tell my boss that we are in badly need of insert a 40 hour delay because of refactoring the projects into maintanable & compilable parts (sharing same dll into each library per purpose/layer). If the delays is about pure project redefining or just splitting out the solution into several projects fully depends on your work. At least the parts where I am expecting problems and are about to change,
Related
I must work with a Visual Studio (2017) Solution that contains 654 projects, and counting. The projects are a mixture of C++ and C# projects - possibly 2/3 C++.
The problem is, VS2017 (we're already running 15.8) is highly unstable at this project count, but for some tasks I need to open the whole solution.
One can (and should) question the design, but please not here. Are there any viable tricks to make working with such a sln bearable?
The problems we have is:
After having fully loaded, it's sluggish as hell, even on our beefy dev machines. Hangs often.
It will crash many times a day. (We isolated a few cases that reliably crash it, like oping the C++ setting dialog, but it's still unstable).
Crashes are often observed when VS peaks at ~ 2.6GB RAM
Not Problems:
Solution load times: The solution is loaded in a decent amount of time. We don't need to optimize for this at the moment.
Compilation times: Devs don't do full-solution builds anyway. (But some tasks require having your corner in the full context of the whole solution.)
I already tried disabling VS Intellisense, but it didn't help. Disabling our VisualAssistX plugin also didn't really help.
Historically the VS team has always said that they're going to fix the problem of VS loading too much at some indefinite point in time. That's one reason why they
haven't made it 64-bit yet as well. Now that they've disabled the selective loading API, you're pretty much on their mercy.
For older VS versions, there's Funnel.
It allows you to selectively load a subset of the projects, automatically loading dependencies. The added benefit is that refactoring, search etc. only works in context of loaded projects, making it much faster. You can also save and organize your filters, making it easier to switch between different subsets.
When placing the curser on a closing bracket in c# for instance, there is a small annoying delay before the opening bracket gets highlighted, and you have to sit and wait before you can use shortcuts such as (ctrl + shift + up/down). It feels like it is intended behaviour for reasons beyond me, so i don't think it is a bug or because my computer is slow (it's not), but it's driving me crazy.
I'm on a freshly installed PC, so i have only testet it in a few programming languages / file formats, and the behaviour only occours in some of them.
The delayed highligh behaviour occurs in .cs (c#), and .css files, but not in .js and .html files, here the code gets highlighed instantaneously exactly like i want it to in .cs files aswell.
I'm using Visual Studio 2015 Community Edition.
I have had this problem as well, since first installing. I can confirm that Update 1 CTP addresses this issue, and the delay is almost gone (maybe 1/8 second now.)
This UI delay was actually called out as a bugfix that was included with the update:
https://support.microsoft.com/en-us/kb/3025135
To the problem that there is a delay highlighting the brackets: In my opinion that has nothing to do with a bug. I think it takes a little while because your code needs to be parsed every time you change something in order to highlight the brackets. When you have many lines of code in one file it is obvious that it takes a little more time than normal.
Here are some tips that may help you:
Click the bracket and press STRG + ´ this will bring you directly to the other bracket. Or you press ALT + ´ and it will mark all your code in between your current brackets. You can look up the shortcuts of Visual Studio in Tools -> Options -> Environment -> Keyboard:
I'd recommend everybody programming in Visual Studio is to change the highlight color of the matching bracket. Have a look at this:
Here you can change all the colors and forms used for specific searchterms. I personally use Visual Assist 2015 to highlight my code (that's why I didn't change anything here). It is way more faster than VS itself and comes with a lot more functions like bracket guidelines who will show you the indent level of your brackets. Have a look, maybe you like it:
Its about 500ms in a newly created console project
500 msec is a magic number in .NET. You can get some insight from the source code for the C# Language Service, accidentally (?) exposed by a Microsoft programmer on github. Most relevant file is probably this one:
internal interface IBraceMatchingService
{
Task<BraceMatchingResult?> GetMatchingBracesAsync(Document document,
int position, CancellationToken cancellationToken = default(CancellationToken));
}
Or in other words, the brace matching service runs as a background task. Such tasks normally run on a thread-pool thread and are subject to scheduling by the threadpool manager. That's where the magic 500 ms number comes into play. The manager attempts to keep the number of executing tp threads down to the number of processor cores available on the machine, the most efficient way to run threads. However, if the existing tp threads take too long to finish their job then the manager assumes that they are bogged down by I/O and allows an extra one to run. It does this once every 500 msec.
So first-order estimate of your problem is that VS has too many active thread-pool threads and they don't complete in a timely manner. Causing the brace matching task to run too late.
Finding out exactly what specific tasks bog it down is technically possible. I can't guarantee success with the Community edition and you'd need a fair amount of insight in how to read thread call stacks to get ahead. Startup another instance of Visual Studio and use Debug > Attach to Process. Pick "devenv.exe" from the list. Let it trundle while it is attempting to find PDB files, then use Debug > Break All.
First place to look is Debug > Windows > Tasks. Pretty unlikely you'll see anything there however, normal is to see none. Next one is Debug > Windows > Threads. You ought to see about 15 active threads back in that window. Hover over their Location column to take a peek at their callstack. Making sense of what you see isn't that simple unfortunately, it will help a lot if you can compare what you see with another machine that does not have this problem.
Since you have this problem on more than one machine, another approach is to look for an environmental factor that they have in common. Things to look for are aggressive anti-malware, a network connection that is too slow or too unreliable, a poorly performing add-in that you like but runs poorly on a VS version it wasn't tested on.
And consider that VS2015 isn't exactly ready for prime-time. Of all the recent VS versions released in the past 18 years, it is probably the least stable. It has a lot of heavy internal changes and there were an unprecedented number of alpha and beta versions with critical bug fixes implemented just a few months ago. Try it again after Update 1 is released.
Seems like this will be fixed in a future Visual Studio update: https://github.com/dotnet/roslyn/issues/1906#issuecomment-145874647
I have not found a definitive solution for your problem.
This was a known bug in the VS2015 review edition.
This links discusses the delay (this link refers to c# btw, not c):
https://connect.microsoft.com/VisualStudio/feedback/details/1033540/braces-are-not-highlighted-correctly-in-c
And there are still similar problems for some VS2015 Community Edition users.
http://www.developerteacher.com/msdn/bracket-matching-highlights-not-working-like-i-had-in-2013-express-4227
Personally, I think you are stuck with a bug and if I were you I'd try the following:
Make sure I had unistalled all previous editions of VS.
Try a repair.
Completely uninstall and reinstall VS2015 if running repair doesn't work
Go back to VS2013 if it drives you cannot stand it, and wait until VS2015 is a bit more ripe on the vine.
One thing I have found with VS, is when it plays up it's painful, it takes so long to install and the worst case was when I ended up uninstalling and downloading everything that was associated with the install. It now works fine. (this was after previewing 2015 and then going back to 2013). You can also try this for VS2015 and also try a new download.
I sometimes will have a look at some previews, but after jumping in with haste too many times with the latest software releases and then repenting with leisure. I am now happy to wait for new releases to be out for a while before upgrading.
Another FYI for you to browse.
This is a link to Visual Studio 2015 RC fixed bugs and known issues. There are quite a few issues and hacks suggested. (not specific to your problem, but still there a few months ago.).
I am assuming you know how to play around with the settings. I've added the obvious, in case it's been overlooked.
I have added this screen shot from VS2013 settings.
Make sure you have automatic delimeter highlighting checked.
Sorry I could not be of more help.
I mostly don't wait for the results or intellisense because it is too slow.
But sometimes, when I am not sure of a type, I would like it to be here, and it takes very long to have the inference run.
However, my CPU is working around 2% all the time..
=> Is it possible to have visual studio be more agressive with my computer's ressources ?
Update
I use Visual Beta 11
while intellisense does appear immediately after loading a solution, it takes a while when modifying the code (around 20-30 seconds)
The F# VS implementation is not stingy about using resources to give you feedback in the editor. If any IntelliSense info is out of date, it will happily burn one full core (or a little more) trying to catch back up. And if any stale information is available in the meantime, it should serve up the stale results. A wait of tens of seconds is unexpected for any 'warm' solution.
(If this is a relatively new install, you might run ngen eqi from a VS command prompt to ensure NGEN has finished after the installation; the F# compiler components are slow unless they have been NGEN'd, and this happens in the background after the VS install.)
If you see IntelliSense this slow, I'd be curious to know more about your solution (number of files, size of files, using type providers?, ...) to identify the problem.
When using Visual Studio I often encounter situations when the IDE freezes while performing some operation. For instance, this frequently happens when I move next statement pointer (yellow arrow) during the debug session, when I unintentionally press F1, step into some low-level function that has multiple instantiations in the binary code etc.
In these situations Visual Studio notification balloon shows up in the tray with the following text:
Microsoft Visual Studio is Busy
Microsoft Visual Studio is waiting for an internal operation to complete. If you regularly encounter this delay during normal usage, please report this problem to Microsoft.
Often the delay is so long that it is faster to kill the Visual Studio process, start it over again, restart debugging session (or whatever else I was doing) and avoid doing an operation that has caused such a delay. However, this still takes too much time. I would like to have a way to stop/cancel the operation that is taking so much time. For instance, in Total Commander this is possible by pressing Esc during such an operation.
Is something like this possible with Visual Studio? Any plugins that allow doing it? Any other way to circumvent the problem?
P.S. Sorry for the lenghty description, but I wanted to explain the actual problem (not ask if certain solution is possible), so that people can think of ways to solve the problem.
P.P.S. Both 2008 and 2010 suffer from this problem.
If you're debugging, try hitting SHIFT-F5. This should stop the debugger, though probably not immediately, faster than what you've described. The program will process the keyboard a lot faster than trying to click menus with the mouse.
If you're building, try hitting CTRL-Break. Again, it may take a few seconds, but it usually comes around.
I've had the problem you mentioned a few years ago, but I can't remember what I ultimately did to fix it.
There may be many different causes of this issue, but for me apparently what was slowing it down was trying to load symbols from symbol servers. I unchecked the Symbol file (.pdb) locations in the Debugging\Symbols options and the problem went away entirely.
run iisreset may solve your problemstart >> iisreset.exe
I'm using VS2008, in a normal mid-size solution.
Sometimes, debug stepping becomes very slow. A padlock gets rendered on the every file tab for every "step" (F10/F11), and it can take up to two seconds for every step. That makes debugging very annoying and slow. Has anyone seen this problem?
I've noticed in VS 2008 that if you have the 'Show Threads in Source' button selected in the debug toolbar that stepping can be at least 10 times slower.
I've also noticed that if your application takes a long time to start in debug mode that this can be resolved if you simply 'Delete All Breakpoints' under the Debug menu. This solved an annoying problem for me even though I only had a handful of breakpoints set at the time.
Silas
Try turning off the "Enable property evaluation…” setting in Debugger options, it should make debugging much faster (read more: Fix: Make Debugging Faster with Visual Studio):
(source: flickr.com)
Disable Show Threads in Source in Visual Studio. and Close Call Stack Trace Window.
In addition to all issues mentioned above.
A "Disassembly" tab (opened in a background) slows down the debugging by 1-2 sec per step.
(Not sure if it always happens like this).
I had the same issue, especially when debugging apps with many threads.
It was caused by the feature "Show threads in source".
See the following link for details:
Code Project: Show threads in source
Visual Studio Single Step Performance Fixes
After disabling this feature, problem has been fixed.
There are many things that can cause Visual Studio to be slow. Excessive breakpoints and Show Threads in Source are probably the two most common, but you don't care what is most common, you care what is making Visual Studio slow for *you*.
So, if deleting breakpoints and turning off Show Threads in Source doesn't work then you need to profile Visual Studio. That lets you find performance problems that are unique to your situation. An explanation of how to do this (which resolved two separate Visual Studio performance problems) can be found here:
http://randomascii.wordpress.com/2013/03/03/visual-studio-single-step-performance-fixes/
More investigations of performance problems in other people's code are detailed here:
http://randomascii.wordpress.com/category/investigative-reporting/
Accepted answer is hardly relevant or helpful!
These are some possible issues that could make debugging extremely slow:
"Show threads in source" (see screensht). If you have a heavily mutithreaded app you won't be able to debug with this option enabled. What this options does is it tries to show in the same file execution position of other threads if they also execute the same code. So, if you have many threads debugger needs to check for all threads where they are located. If you have many threads this might make each step with debugger extremely slow.
Many conditional or even regular breakpoints. Especially if these are in some inline functions of some header file.
"Show external code" enabled in call stack also makes it slower.
Disable “Show Threads in Source” if it is enabled, and also close the Parallel Stacks Threads, Tasks, and GPU threads windows if it they are open. Those cause the debugger to walk the call stack for every thread in the process.
Yes, Visual Studio is extremely slow at debugging at times. There are a number of additional steps (in addition to turning off the Enable property evaluation" setting) you can take to speed up the process. Essentially, it requires massive amounts of RAM, so performing a few things to free that up will help.
Go into the preferences of Visual Studio. Look for all the options relating to animating menus and so forth. These have a tendency to be intensive at times, while not specific to debugging as you usually aren't opening up menus, it does seem to help.
On the computer itself, if you right-click on my computer. Go to the advanced tab and under performance. If you adjust your computer for best performance it'll speed things up. It gets rid of any nice styles on your computer, but it'll free up some of the memory you are wanting.
Close any unnecessary programs. The more memory you can give Visual Studio the better it is going to behave.
Here's a link to some guidance on Mike Stahl's MSDN blog, with respect to resolving debugger slowdowns
I ran across this because conditional breakpoints in my app's hotspot killed my debug performance. Personal BKM: resolve potential performance issues before you leave for the night, for you may not remember them in the morning.
Another cause of single step slowness is use of Intellitrace (available only in Ultimate). To turn it off, Tools | Options | IntelliTrace. Uncheck Enable IntelliTrace.
The "Show Threads in Source" suggestion did not help.
But I fixed it by enabling Tools:Options:Debugging:General - > "Require source files to exactly match the original version".
Mine was unchecked initially, but after changing it stepping through code in VS2008 is now back to normal speed.
What helped me was disabling Diagnostic Tools.
Tools / Options / Debugging / General / Enable Diagnostic Tools
Visual Studio 2015 (Version 14)
I experienced this problem after enabling ".NET Framework source stepping". Stepping got a lot faster after turning this off. In particular, turning back on "Enable Just My Code" (Options > Debugging > General) removed about half the lag I was experiencing.
The other half was caused by loading more Symbols than I needed (Options > Debugging > Symbols). At one point I needed Symbol locations defined, but I didn't anymore, so I was able to uncheck them all and click "Empty Symbol Cache". If you have _NT_SYMBOL_PATH listed it means you have this environment setting defined, and Visual Studio won't let you uncheck it. You'll need to remove the setting. More about Symbol settings (https://blogs.msdn.microsoft.com/visualstudioalm/2015/01/05/understanding-symbol-files-and-visual-studios-symbol-settings/)
I had the same problem, I deleted all my variable watches and it helped a lot! Because each step during debug, it reloads all watches and it takes time...
Solution : From the Debug menu, choose Windows, then Watch, and click on Watch1, Watch2, Watch3, or Watch4. The menu will appear and right click on them to clear them all.
If you have a virus scanner (with realtime scans enabled), check if C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Remote Debugger\x64\msvsmon.exe* is excluded from the scan.
In my case, debugging became very slow after the companywide rollout of new virus scanner. After a while, we found out that the realtime scan of msvsmon.exe was the culprit.
*modify path as per your installation folder
clear all entries in the watch window.