When I'm debugging, Visual studio allows me to place a breakpoint anywhere, which in turn allows me to step through the code. However, I sometimes encounter a problem where what I THINK is the first method called, actually isn't the first method called. For example, I THINK the onclick for my button is called first, but actually, it's another method on the Master page, or even something in my Global.asax, which then changes a variable, which then changes the code path my code takes, which then breaks my code.
I'm looking for something that's basically: press this button in Visual Studio while debugging, then do something that causes a postback (or otherwise something to happen in the backend), and Visual studio then automatically goes to the very first method called and starts stepping through the code at a steady but understandable pace (longer method calls notwithstanding, and only going through my own code, not anything in library references) until you tell it to stop.
I know this sounds like profiling, but it's actually not. Profiling just passively gathers data while you do your thing, and shows it afterwards. There's no live feedback on what happens, and I can't make heads nor tails of the result of the profiler. In fact, last time I used the built-in VS profiler, one of my top 3 intensive methods was the profiler itself, if I read it correctly.
Ideally, what I want is something that looks and feels like an automatic debugger, something that goes F11 every .5 seconds, but skips external DLLS.
Does such a thing exist?
Runtime Flow extension (developed by me, 30-day trial) can show you paths the code takes in real time. Thought it is separate from VS debugging and requires some manual configuration for ASP.NET projects.
This is a ridiculously complicated requirement. I'm not saying it's a bad idea, and it would be amazing if such a thing was possible, but I very much doubt it's available anywhere. I've never heard of anything like this as a VS feature or even as a plugin.
Related
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.
We have started encountering endless loops in our engine recently and I have no idea how to effectively fight them. The app simply freezes for eternity and I am unable to stop it's execution to understand what is going on. Placing normal breakpoint in major places (update loop) does nothing. I am almost certain that the problem is in a continuously running loop somwhere, but due to the code's size I cannot even start guessing where to look for it.
So, my question is how do you break app's execution in Visual Studio at some arbitrary place in the code, where the app happens to be at that time? Something akin to "stay where you are". Is it even theoretically possible?
Sure, use Debug + Break All.
This of course doesn't necessarily break your program at a nice address that happens to match one of the statements in your program. Pretty likely if setting breakpoints didn't invoke a break. You are likely to see a notification from the debugger that it cannot display source code. Or for that matter, it might not have selected the correct thread.
So first thing you want to do is use Debug + Windows + Threads and make sure that the correct thread is selected. Double-click the one you want to debug. Next thing you want to do is look at the Debug + WIndows + Call Stack window. It should at least display some of your methods, giving you a hint how it ended up in never-never land.
And it isn't unlikely that it got deadlocked on native code or an operating system call. To see that, you'll need to enable unmanaged debugging. Project + Properties, Debugging, tick the "Enable native code debugging". And make sure you've got the symbol server enabled so you'll get debugging info for the operating system DLLs. Tools + Options, Debugging, Symbols.
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 have to debug a very big program, which takes around 10 minutes until it reaches the most important debugging state. I just want to modify some values in this part of the program, but sometimes I would like to go back and modify them again, like travelling to the past. As far as I know it is called historical debugging. Reading some info it seems it has been implemented in Visual Studio 2010. But I only use Eclipse or Xcode or vi :)
I wonder if know some other software with these capabilites.
By the way, I ask about your opinion, do you think it will be possible, once I reach this state of my program, to modify some small part of the code, after the breakpoint, and compile it again (supposing it does not affect to the past execution and code) so I can test it without recompiling?
Thanks
Also discussed here
Mostly only available for interpreted languages like Java (ODB). And I am not sure if you can continue from some point of execution with changed data.
Have you tried to set watch point in Eclipse that would break as soon as a variable reach a specific value? This means your code executes normally until it breaks your data and execution stops so that you can see how you code got to this point.
Basically I'm wondering if I can save myself updating my code with System.Diagnostics.StopWatch, and somehow just get away with using the debugging features of VS (2008 in particular)
I.e. if I put a breakpoint before and after my method call, and then 'run' it. Is there anyway to tell how long VS was running before it stopped again? (Other than staying at the station and looking at the computer's clock of course)
If the answer is yes, please explain how.
As far as I know, no such a feature is built into Visual Studio.
Rather try a profiler. EQATEC Profiler is free and does exactly what you want i.e. time spent in each method and it's really easy to use....
You can use DateTime.Ticks. Rather than setting a breakpoint save the DateTime.Ticks component in a temp variable. At the point of second break point use another variable to store the DateTime.Ticks component.
Now time elapsed is Variable2 - Variable1.
There are 10,000 ticks in a millisecond.
I got all excited about replying to this post, until I actually tried it and realized that .NET projects don't support the #CLK pseudoregister trick! This sucks.