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.
Related
I have been suffering from the all too common 'Waiting for a background operation to complete...' message in Visual Studio 2012 (Professional) for a while now but it has been fairly sporadic.
Lately though, I am really struggling to use Visual Studio as pretty much whenever i try and do anything with any Razor views (mostly clicking to move the cursor) visual studio hangs and the above message appears for about a minute at a time.
(If when its finished doing stuff i then click in the view again, the process repeats, and repeats, and repeats.....)
I have searched high and low, and read loads of articles regarding this and peoples suggestions and tried changing indentation settings, resetting settings, etc but none have worked.
Has anyone come across something else that may work as this is seriously impeding my ability to use visual studio and sadly provoking much cursing.
I also had the same issue with VS2012 and unfortunately I had to format my pc after trying all the following solutions:
Move/clean the symbols cache
Reset VS preferences
Install Upgrade 2
Uninstall/Reinstall VS
After formatting and reinstalling VS2012, it started working like a charm again (obviously).
Sorry for that.
I know I asked this question a while back, but I thought best to put up my findings as they may help others.
The exact reason for the Waiting dialog is still unknown, but I have since moved my project to a local disk and implemented Team Foundation server to perform the hosting and backup of the main project files.
Since moving to local disk and using TFS, I have not experienced any more of the VS Waiting dialog.
Check if IIS or another process (BizTalk maybe) is locking your DLLs/references
Kill/stop IIS if it is
I recently watched a bit of Notch's Ludum Dare live stream. He uses Eclipse's hotswap feature extensively while he works on his game. (here is a video of what I am referring to http://www.twitch.tv/notch/b/302823358?t=86m30s)
I would like to do the same with C# and XNA. Fortunately, Visual Studio has an Edit and Continue feature. However, I would like to edit my rendering code while it is running instead of pausing it.
Is it possible for me to setup Visual Studio to do the same? I noticed that there is a checkbox for Break all processes when one process breaks. Is it maybe possible to set up my rendering loop in another thread so that the game keeps rendering while I make a change?
Update: This answer is now available as a video.
I've been struggling to find a way to do this. I know this doesn't answer your exact question. But really what you are looking for is a workflow where you can make code changes with zero (or near-zero) delay, and I think I've figured out the closest you can get with just Visual Studio. (And therefore avoiding a huge engineering effort and dealing with "abnormal" projects).
The way to achieve this workflow is actually astonishingly simple, once you think of it:
Use shortcut keys!
The first way I came up with is to just use the normal edit-and-continue method of setting a breakpoint. Only by using the keyboard you can do this considerably faster. This only works with code being called in a loop (eg: draw/update). Click the code you want to modify, add a breakpoint (F9), the breakpoint will almost immediately be hit, modify your code, remove the breakoint (F9), and then run the code again (F5).
This is pretty good. You don't have to use the mouse to hit the relatively small "Add breakpoint" target in the left hand column. But it does move the input focus to the beginning of the line, so you generally have to use the mouse again to fix that before you can start editing.
I want something faster. So I came up with a better solution:
Again, using the keyboard: Press Ctrl + Alt + Break to "Break All". This enters the debugger almost instantly, without having to worry about setting a breakpoint or if the code you want to modify is running in a loop. This will change the editor window and caret focus to the document where execution break, but you can then immediately fix it by pressing Ctrl + - for "Navigate Backwards".
Then you can make your edits and simply press F5 to see them in action. You only have to use the mouse once (or not at all) to initially pick where you want to start typing - just as you would expect.
Admittedly Ctrl + Alt + Break and Ctrl + - are horrible key combinations for something you want to be able to do extremely quickly. And it would be better if there was just one key to press.
If you have the full Visual Studio, you could probably turn it into a macro or add-in. Express doesn't have those - so the best you can do is modify your key bindings (Tools, Customise, Keyboard...) and bind it to two keys that are adjacent, that you can press in quick succession. Or use an external macro utility.
Personally I have set up the two key combinations to be pressed in succession (you don't seem to need a delay between the two) by a macro set to a spare button on my mouse. Which works reasonably well - as I'm usually selecting text at the same time. I might add a keyboard macro later too.
So far I've identified two minor pitfalls of this method:
When you run the app again, Visual Studio gives it focus. It would be nice if it kept focus. Adding a left mouse click to my macro is a partial solution to quickly re-editing code.
"Navigate Backwards" does not retain the text selection, only the caret position.
i can tell you how, but you arn't going to like it:
1) run your game executable in a visual studio instance (game.exe --> vsInstanceA)
2) code your modifiable code in a seperate dll, using a seperate visual studio instance (modifiable.dll --> vsInstanceB)
*note that doing this lets you compile your modifiable.dll, thus doing compile time error checking, etc.*
... and now is where it get's tricky ...
3a) game.exe needs to reference the modifiable.dll. NOT the .vcproj, the actual dll
3b) when you hit a "magic key" (have game.exe look for a key-press), have game.exe unload the modifiable.dll, and reload it. You can easily do this via the Assembly and AppDomain classes provided in mscorlib. Of course this means you need to unload any dependant systems in game.exe.
note, there's a lot of hand-waving in this 3b) section, it's quite a lot of work but pretty straight forward (example google search: https://www.google.com/search?q=dynamic+load+dll+.net)
... and after that, you are good to go ...
3-alt) some other choices if 3b) doesn't suit you:
you can invoke msbuild.exe to rebuild modifiable.dll when you press
"magic key"
you can use the CSharp compiler dll's to dynamically
recompile each class instead of the entire modifiable.dll
but unfortunatly, in my 10+ years of .net development, this is the only way, unless someone has created a 3rd party product to do it (IE: they do what i mentioned, for you)
This may not be exactly what you're looking for but it's what I've been doing. Just throw in a break point while your game is running. Once it's stopped, you can edit things, remove the break point, and then hit F5 to continue.
For the most part, this allows you to edit things while the game is running and continue running the game afterwards but it doesn't work for everything. You can't add or remove class level things and also can't add/remove entire functions or the parameters. Mostly, I do this to test out different numbers and equations for smaller things that get hit every update.
To answer the original question "in Visual Studio 2010 without pausing execution?"
No. For Java there is JRebel which allows this.
I can quickly imagine why Microsoft haven't done this - if you have some sort of committee or group of people designing things - it's easy for even one person to come up with good arguments where this "dynamic software updating"/hotswap will break. It's just too easy to shoot down. Or if they proceed with it, it will be through some entirely new "enterprise framework" that requires lot of steps, work and understanding to get anywhere, because they want to use it for complicated online scenarios.
I'd prefer there was some simple way to do this - I'll take the risks, and put up a lot of disclaimers that if you want hotswap services that talk to external systems then you need to use that complicated framework or whatever.
The most typical scenario where this could safely be used with low risk is prototyping and tweaking some sort of engine with either high startup cost or more likely, to study behaviour if something running in the engine (like rules) is buggy and to exhibit the bug, a lot of things has to happen and it's possible you don't encounter the bug always. That is the case where having this could save weeks of debugging time, atleast would have in my case.
I'm used to work in Java using IntelliJ Idea + DCEVM (Dynamic code evolution VM).
Unfortunately i haven't found anything getting closer to that configuration at Microsoft C# platform. It really sucks and you can't do much about it. You can use some user defined macros, but you can't still do much in Edit and Continue mode without restarting Debug session).
However if you can, try to use newest .NET Core which offers much better productivity using Dotnet Watch. Still not so fast as DCEVM but much better than traditional VS + .NET hot reload experience. Details here.
I've got a relatively small project written in ASP.NET MVC3. After working a while, Visual Studio 2010 becomes very slow in Razor views (other file types work fine). With "slow" I mean "every keystroke takes around 1 second to register". It doesn't matter what that keystroke was - typing a single letter is as slow as pasting a screenful of markup. During this slowdown VS2010 consumes 1 CPU core to 100%. After I restart VS2010, everything goes smoothly again for a small while. This happens in any and all Razor views.
My PC isn't the best, but it should be enough: Core 2 Duo 6700, 4GB of RAM (currently only 75% filled with VS2010 being slow and all, so it's not a RAM shortage), Windows 7 x64.
The project is close to an end, and I remember that for most time there were no problems. This has started only recently, although I cannot imagine what could have caused it.
Does anyone have any ideas about what could be wrong and what could be done to fix it?
It is plugins - TFS/AnkvSVN and ReSharper have all caused problems for me.
Turn them off one by one, to discern which one (if only one) is causing you grief.
When you find the culprit, make sure you keep up on any patches with it.
In extreme cases, turn if off if you have a long development session and don't need it the whole time (SVN for instance could be turned on when you are ready to do commits and check ins, etc.)
The issue is resolved for me, by installing the Mvc Html5 Templates.
After the installation, I picked XHTML5 and then back HTML5 from the "Target schema" combo box. After that, the paste was instant!
Edit: I uninstalled "Mvc Html5 Templates" and the issue didn't reappear. Perhaps it has something to do with the "HTML 5 Intellisense"
Have you installed sp 1 it fixed some performance related issues when loading IntelliSense for markup
Run the Resource Monitor (CTRL+SHIFT+ESC, click Performance tab then Resource Monitor button at the bottom). Pay special attention to disk I/O and perhaps CPU usage.
Sort disk I/O by Total B/Sec descending. As you type, see if it can identify a process which is causing the issue. Hopefully it's a virus scanner or some other famous performance destroyer and not the Visual Studio process itself, which wouldn't be very helpful.
Have you tried opening the same project on a different machine? This will give you an idea whether issue is in the project or VS install. Quite obvious, but is there anything in the event viewer. Are you connected to a domain while this is happening?
Well, for me the problem has turned out to be anti virus - we use (or are made to suffer) Sunbelt Vipre on our workstations and as soon as I switch off active protection (so that's basically disabling AV completely) all of a sudden all the performance issues in all windows are gone.
Sorry for adding another answer, but there seem to be lots of different causes, so - lets list all possible fixes here.
I tried disabling ReSharper and other addons - did not work. What did work - is reapplying the SP1 again.
PS. Weird, I know. Don't ask, no idea... My guess is - VS was "repairing" itself silently at some point and restored some non-SP1 components.
PPS. You might also want to try disabling "Productivity Power Tools" addon. If you have ReSharper installed - almost all the PPT features are already there, in ReSharper.
PPPS. I have a blog post with several performance tips for Visual Studio & ReSharper, might come handy..
Have you tried Cleaning the solution?
In my case, high CPU usage started out of nowhere (WPF project). Restarts of Visual Studio didn't help, neither disabling/uninstalling addons. But Cleaning the solution did help!
I was experiencing a very similar issue on a large cshtml file in VS 2015 and was solved for me by turning off all of the automatic formatting options in Options > Text Editor > C# > Formatting > General:
I then use the "Control+K,D" key combination to format the page once I have finished making the necessary code changes.
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 saw that Beta 1 of VS2010 was publicly availible.
My question to those of you who has tried it is: does it work good?
Will it cause my computer to blow up in tiny pieces? Will it crash randomly? Will it work with some minor glitches? Or is it just perfect from bottom up?
I'm only coding school- and hobby-stuff, so nothing that someones life depend upon, but i still want software that works. How close to a final product is it? Is it worth trying?
It's a bit slow, and there's no offline MSDN, but it's worth trying IMO. Having said that it's slow, I still use it on my NC10 netbook, so it's clearly not that bad :)
I've got it side-by-side VS2008, and that hasn't caused any problems.
I've seen a couple of glitches (once the keyboard handling went completely wonky) but it's certainly usable. The main question is what you want to get out of trying it - in my case I absolutely need to code against C# 4 to explore the new features. I do most of that from the command line in fact, where the speed of VS obviously isn't an issue, but it's nice to see the VS-specific features as well (like the debug threading views for Parallel Extensions).
It seems more or less usable on the .NET side. The C++ side is a bit more sketchy. On one hand, they've added support for some very nice new C++0x features, on the other, they've broken some absolute fundamentals.
Your plain old main function won't compile in 32-bit with unicode enabled. (Workarounds: Either compile as 64-bit, disable unicode, or rename the function to wmain).
This seems to me to be a strong hint that the C++ side of things is nowhere near release-worthy. I'd probably wait for beta2 before doing any serious work with that.
I would say it is great, but the performance hurts a bit.
Here is an idea for you: Install it into a VirtualPC. Then you can play and not care what it does. You don't like it, delete the VPC image and keep on trucking. That is how I play with Microsoft betas now. I never install them on any real machine - too risky.
Usable: Yes.
Recommended: Not if you'r a touchpad-addict or dislike crashing apps.
I've been trying it for 2 weeks now coding small C#-projects and these are my impressions
Reasons to use 2010:
Looks good
Multi monitor support
I can see myself using the code templating but right now i couldnt find any really useful stuff except for reducing the fontsize of comments.
Zoom in the editor
Select a variable and then press shift+up/down to go to next usage of this variable
Ctrl+, brings up instant search of classes and functions in the entire project. (i've become really addicted to this)
Floating watches for single objects
Reasons to not use 2010:
TOUCHPAD SCROLL DOESN'T WORK IN THE EDITOR!!! (this is reason enough to not upgrade if you are using it on a laptop)
I've had some random app-crashes in the middle of just writing code, once or twice per day maybe.
UI sometimes freezes randomly for about 30seconds and then returns to normal.
It started to use 100% CPU power from one of my cores once when it was minimized in basic editing-mode and i was doing other stuff in other programs, i only noticed it because the fan started to go wild.
Otherwhise it's pretty similar to 2008. I haven't noticed any difference in speed like other people say.
You need to ask yourself: what is the advantage for you in using VS2010 over VS2008? I would suggest that there is no advantage if all you are doing is "school- and hobby-stuff".
I'm still using VS2008 for business related stuff (and, indeed, VC6 for some stuff). I prefer to wait until all the early adopters have tested it (and Microsoft has released at least one service pack after the real product release) before I do their testing for them.
It seems to co-exist with other versions of VS without causing any problems.
Regarding the slowness - it seems to be the UI that is slow, rather than building. Once it's going it doesn't seem much slower on my fast quadcore. I've yet to try it on my laptop.
It's usable enough, the small glitches that I've encounter weren't that bad. However, certain VS extensions(like XNA) don't work in VS2010 at the moment.
It's fun to toy with. Not usable for me, cause re#er does not support it yet (had to install TestDriven .NET which works through keyboard shortcuts only to run my tests).
Gave me an insight how addicted I am. :/
Btw, on Win7, without virtual pc it seemed even faster than vs2008 for me.
VS2010 doesn't yet support mobile device projects, which might or might not matter to you.
VC++ wise - VS2010 has a built-in 64-bit compiler, VS2008 does not.
You can supposedly add 64-bit support to VS2008, but it takes some effort.
I've been using VS 2010 beta (with .NET 4.0 beta) on Windows 7 RC. I've been trying to rewrite parts of a large-scale business application in it to see what can be done with it.
The UI freezes frequently. I'm talking 1-10 minutes between freezes. The UI does not come back, so I'm forced to kill devenv.exe every time it happens. Microsoft probably puts my error reports in their spam folder by now.
For me, VS 2010 beta 1 classifies as unusable. However, it's fast, the new IDE functions are very handy, and it's pretty. I keep coming back to it despite my resolutions to wait for a stable build.