During step-by-step debugging, I often use "step into" to halt at every line in the section that I am debugging, to see all my code that's executed.
But library calls can disrupt this work flow: The debugger will jump into some STL file and continue there. I then have to press "jump out" to go back to my own code.
Is there a way to prevent the debugger from opening STL source files? A blacklist or a setting somewhere? I work with native C++ code. The "only my code" debugger setting unfortunately only works for managed code.
good question, the debugger constantly jumping into everything is indeed a huge slowdown and distraction during debugging. Luckily there's a solution:
open your registry editor, navigate to
HKLM\SOFTWARE\Microsoft\VisualStudio\10.0\NativeDE\StepOver
(add \Wow6432Node after SOFTWARE if you're on a 64bit machine, this casued me headaches in the past).
Add a new String Value (REG_SZ). The name is not so important, I used NoSTL for clarity and set it's value to
std\:\:.*=NoStepInto
This tells the debugger to not step into anything matching that regex so it will skip every function (global and class level) in the std namespace.
By using StepInto you can add overrides for specific methods, and you can still use breakpoints off course. It's also handy to add some of your own methods that get stepped into often but of which you know the result by head.
Here is a more detailed explanation, google on NoStepInto for more scattered information.
The answer is as above mentioned, but in case you use VisualStudio 2017 or it didn't work for you, then try the following:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\Packages\Debugger\Visualizers
Open the following file with notepad or whatever you have:
default.natjmc
and add this line:
<Function><Name>std\:\:.*</Name><Action>NoStepInto</Action></Function>
The 'name' means the value of the registry key in that file and 'action' is self-explanatory.
If you want to add the registry key too, (not sure if it is necessary), then you will find it here:
\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VSTA\8.0\NativeDE\StepOver
At least, that was the path in my case. It took a good hour to find these, so I hope that it will help somebody.
Remove the 'Wow6432Node' if you have 32bit machine, as above mentioned.
You don't use F10/F11/Shift+F11??? Those are "step over", "step into", "step out", and there are many more that are useful. Much more usable than hunting for buttons, and you never have to take your eyes off the source code.
In general you're well served by using keyboard shortcuts in Visual Studio instead of the mouse. Not just for debugging, but everything. Learn 'em, you'll love 'em! You probably can't learn them all at once, just pick a few functions you use often, get used to them, then start on a different set. It becomes second nature over time.
Sorry that this is off-topic, but your original question was beautifully answered by the previous poster already, and I thought I'd help with something else :)
Related
In Visual Studio, I have a block of code. I highlight it and use Ctrl+k+c to comment out the block. That adds "//" at the start of every line I highlighted. I then try to submit my code... and I run into StyleCop rule "SA1005" that requires all // to be followed by a space or be changed to ////. I would really like to modify Visual Studio so that ctrl+k+c adds "// ". I have not found any extensions or options that make that happen. Does anyone know of a way to do that change (short of writing my own new VS extension)?
My coworker tells me that you can also just hit Ctrl+K+C Ctrl+K+C (that is, apply commenting twice), and it will do ////code. That will pass StyleCop. Do the uncomment shortcut key twice to undo. Apparently, StyleCop doesn't care if there's a space after four slashes, only after two.
It seems some people really like this rule behavior. People will comment out code with a single set of // if they are playing around with stuff but do not want to forget and check it in that way. SA will fail and the code will not go in. Once you really mean to comment out of the code and check it in, then you comment it out again and you are good to go. This, they claim, has saved many from a bad check-in.
You don't need to write your own VS extension, there is already plugin GhostDoc that we are offering - you are welcome to use the free version - and it will generate StyleCop compliant XML Comment templates (which you can tweak too). GhostDoc also generate the comments on triple-slash (///) just like the VS does.
Does it use modification timestamp or/and does it check whether the actual content has changed (e.g. by comparing the checksum)?
Edit: I need to know this since I use Git for source control and often change branches. It appears that sometimes even if I change the branch back and force (e.g. from develop to master and then back to develop), the VS rebuilds half of the sources files. I wonder why this happens and why does it happen sometimes and does not happen the other times.
Since Visual Studio is a closed-source project, I bet only developers would be able to give a definite answer on how exactly does it work. However, for my purposes it is enough to test some scenarios.
I have tested it with a small solution and a couple of files in it (one header and two source files). Test results bring to the following conclusion. Visual Studio looks for modification date and time. Even if the file content is the same - it compiles this file and also any other files that include it. If the modification date and time are the same - it won't recompile it even if the content is different. Visual Studio ignores creation and access dates and times.
I'm guessing it uses FileSystemWatcher on the project directories and linked files (if any), just because it's the right way to do this kind of thing.
Some googling finds for more about this class (or just look it up yourself):
http://www.techrepublic.com/article/use-the-net-filesystemwatcher-object-to-monitor-directory-changes-in-c/6165137
http://www.dotnetperls.com/filesystemwatcher
Of course when the source file is open, it's content by the time of editing, as wel as any user changes (even not saved) are loaded in the RAM, but it doesn't compare it to disk content (that'd be too slow), it listens to a system event when the system tells it the file changed.
Update:
Probably not that class itslf, but the Win32 version of it, you know most of the system related .NET functionality classes are just Win32 wrappers.
From this StackOverflow answer: How does FileSystemWatcher work on another computers directory?
I think it wraps this API (not sure): http://msdn.microsoft.com/en-us/library/aa365465.aspx
Update 2:
This is Microsoft's approach to monitor file changes:
http://msdn.microsoft.com/en-us/library/chzww271(v=vs.80).aspx
Update 3
This is an old answer, and it was mentioned above that it was a guess, as Visual Studio is closed source as mentioned in other answers. It's worth mentioning that the accepted answer suggests Visual Studio looks for file modification dates instead, which suggests it doesn't use the approach guessed in this very answer, and that it was wrong.
I hope the reader didn't mind the effort given to rationalize possibilities in this answer (causing reader discomfort or down votes). Keeping it for archival reason only.
I'm getting this strange behavior when I launch a program without selecting "Step Into new instance". It launches the program as if I had, requiring me to manually hit F5.
If I explicitly select to step into the new instance, I have to hit F5 twice before it proceeds. I've tried restarting, and messing around with the exception options. It's not an exception. And no, there isn't a breakpoint defined on the first line.
Has anyone seen this before?
I'm going to take some guesses here:
Try closing the solution then moving or renaming the *.suo file for this solution (the *.suo file keeps some information like breakpoint settings and certain UI states - it probably shouldn't be in version control if it is). Reopen the solution and see if it behaves any better.
If not, try the same process, but rename/move any *.vcxproj.user files (which have per-user project settings, and also probably shouldn't be in version control). If you're using some other project type than C++, there will be slightly different names - but I think they all end in *.user. There might also be *.vcxproj.<user name>.user files that you'd want to handle similarly.
If one of these turn out to solve the problem, you might want to look at the file to see if there's something that would tell you what the problem was (.vcxproj is quite readable XML, the *.suo file is some undocumented binary format, so you probably wouldn't be able to identify anything in there).
I thoroughly enjoy the amazing power of LINQPAD (thanks, Joseph Albahari!) and particularly LINQPad's Dump method. Frequently I take an existing Visual Studio project and move it into LINQPad for the sole purpose of adding a couple Dump statements to see what the data looks like--though Visual Studio's data popups are certainly useful, the Dump output is just much easier to digest. To do this, I open each file I need from the current project, copy and paste the individual classes over to LINQPad, add assemblies and using statements, attempt to run so that LINQPad will tell me what I missed, and repeat until I find all the orphan references.
This method seems antithetical to the elegant, streamlined nature of LINQPad. Is there an easier way? Any chance of seeing "Import Project" on LINQPad's File menu any time soon? If not, I may end up writing a utility myself...
If you just want to call .Dump() in VS, check out this:
http://code.google.com/p/linqpadvisualizer/
Importing an entire VS project into LINQPad might be impractical... but I'm going to look in to whether just references can easily be copied over from a .csproj.
LINQPad is awesome and I also manually import projects occasionally. I haven't heard Mr. Albahari mention anything about "Import Project" functionality. And I'd be surprised if he would be interested in implementing something like this anytime soon.
Of course, he is very receptive to suggestions so I recommend posting your idea in his Nutshell forum which he frequents.
Additionally, check out the TypeSerializer in Service Stack libraries. I believe its Dump extension method is wrapped by LINQPad's which then encodes the output in XHTML. It might just be easier for you to use it directly in your code.
I'd like to create a script that will configure the Visual Studio IDE the way I like it. Nothing vastly complicated, just a few Tools/Options settings, adding some External Tools, that kind of thing.
I know that this can be done inside VS with Import/Export Settings, but I'd like to be able to automate it from outside of VS. Is this possible, and if so, how?
Edited to add: doing it from outside of VS is important to me -- I'm hoping to use this as part of a more general "configure this newly-Ghosted PC just the way I like it" script.
Edited again: the solution seems to be to hack CurrentSettings.vssettings, or use AutoIt. Details below.
Answering my own question, in two ways:
In VS2005/8, the things I mentioned (Tools/Options, External Tools) are all stored in the CurrentSettings.vssettings file, in the folder "Visual Studio 200{5|8}\Settings". This file is just XML, and it can be edited programmatically by anything that knows how to parse XML. You can also just paste a new vssettings file over the top of the default one (at least, this works for me).
The larger question of configuring a virgin PC. It turns out that not everything I want to change has an API, so I need some way of pretending to be a user who is actually sitting there clicking on things. The best approach to this seems to be AutoIt, whose scripting language I will now have to learn in my Copious Free Time.
An easy way is to use the macro recorder to do something simple, then look at the code it produces and edit it as you see fit.
On my machine Visual Studio stores it's local settings in a file called VCComponents.dat. Its a text file, so perhaps you could find a way of placing your settings directly in there.
The file is stored in my users local AppData\Local\Microsoft\VC folder