I have an error which is occurring only very late in my code (after it's been running for ~20 minutes) and so trying to pinpoint exactly where it is is tricky because I have a lot of recursive function calls and if I go too far the important variable values may have been changed. Is there a way I can set a kind of save point where all the variables have their values saved and which I can jump back to after I've done some exploring rather than having the run the whole thing again from the beginning?
I found this and just wanted to point out that Roger Lipscombe's comment is what I was also looking for:
Precisely: IntelliTrace https://learn.microsoft.com/en-us/visualstudio/debugger/intellitrace?view=vs-2022
and
Historical Debugging (which is part of IntelliTrace) https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2015/debugger/historical-debugging?view=vs-2015&redirectedfrom=MSDN
Only available on the enterprise version of Visual Studio
I have a workaround for this kind of issue: Using the Data Breakpoint, at least, it could output and save the value manually, and it also can help you check that what value was applied to your code line, I just get this idea from this case I met before:
Visual Studio. Debug. How to save to a file all the values a variable has had during the duration of a run?
If IntelliTrace tool is helpful for you like Roger Lipscombe's suggestion, one idea is that you could use IntelliTrace Standalone Collector tool without the VS in one machine:
https://msdn.microsoft.com/en-us/library/hh398365.aspx
Related
I'm debugging something (in Visual Studio 2017 and 2019) where, somewhere, a number's changing between an old version of code and a new version. It'd be useful to be able to recursively dump the values of fields in an object from the debugger for comparison. Especially where the dump is large and can be run through diff rather than compared by eye. Ozcode looked promising, but the trial is doing nothing. I suspect Ozcode only works for C#/.NET apps and I'm in C++ native.
I can navigate manually through the objects in the debugger and explore all the field values so clearly VS has access. I can query the values of the fields in the top level of an object in the Immediate Window by typing something of the form
?MyObject
I've seen mention of the possibility of running a loop in the Immediate Window- doesn't work here. Nor does using other suggestions of commands to dump to JSON using .NET assemblies, because I'm not in .NET
Using the Package Manager Console as a hacky way in, I can run PowerShell scripts that get at the debugger and iteratively dump fields to text to as deep a level as I want. It's easier than adding exploratory code and the scripts can be created and run while stopped at a breakpoint which makes it easier to explore what's going on, but it'd be so much easier if there were an extension adding a dump option to the context menu of an object in the debugger. I don't see anything obvious when searching. Does anyone know of such a thing?
I have placed a breakpoint in my F# code to examine the contents of a particular list. The count at the top clearly says that the list contains 93 elements, something I have confirmed separately in SQL. But the debugger gets truncated after the 51st element, as can be seen from the snippet below:
Can someone please tell me why I cannot see the entire list? I don't remember encountering this error before. Do I need to set some configuration variable somewhere?
Thanks in advance for your help.
This is baked into the runtime, and was evidently a deliberate design decision at some point. See the relevant line in prim-types.fs
Not sure why this limit was imposed. You can file a bug on the Codeplex page if you want to see this changed.
To preface this I am an Emacs refugee on Visual Studio 2010's shores and am certain that I am working against the tool. Please could someone point me in the right direction. My problem is the MyProject.csproj file is kept under version control using TFS and my coworkers have made a number of changes that no longer get along with my version. Not a problem, I can just merge the changes and make things right. But I can't, or rather I don't know how to. The compare tool in VS only taunts me, it won't let me pick and choose differences like I need to.
What I would love to do is just use Merge in Emacs, run through the file hitting L(eft), R(ight), B(oth) and be done with it in no time. What I don't understand is why there are certain changes that are accepted by default, that I cannot alter. I think that what it is doing is identifying changes that I made to the ancestor document and forcing those to be made while providing me the option of merging the changes from my coworkers. My issue is that these things are contradictory and I would like to ignore my change to Line 12 while accepting the Repository's Line 42 but applying my Line 106.
But I cannot figure out how to tell it "no" to Line 12.
This has to be common, what does one do in VS to get this to work?
Thanks!
The standard diff tool that comes with Visual Studio ... blows. Its not intuitive and doesn't work all that well.
But its very easy to integrate different diff tools. I'm using this one:
http://visualstudiogallery.msdn.microsoft.com/en-us/dace3633-0b51-4629-85d4-c59cdce5bb3b?SRC=VSIDE
(no affiliation; its free so don't ding me for spam kthx). Works pretty damn good. You might find one out there better suited for your tastes, in which case you can integrate it into visual studio. (again, not associated with me!)
I advise you to use WinMerge to compare or merge files with VS
You can define as Will said.
I have a VS solution containing several projects. While debugging a particular project all the source files are locked by VS. I would like to unlock sources that the debugee doesn't have dependency on. Is there any way to do this within one solution?
UPDATE:
I'm using Win XP SP3 32bit. Visual Studio 2010, C#. Edit and Continue is enabled. The solution contains 6 projects (number in not important actually), 5 of them depend on the data access layer project which uses Entity Framework. None of the 5 have any mutual dependencies. They are WinForms and Console applications. I would like to be able to run one of the projects and make changes to others without stopping the first. The problem is starting and stopping the project take considerable amount of time.
The Edit and Continue feature is preventing you from editing files if the debugger hasn't stopped the program. The simple workaround is Debug + Break All, you should then be able to edit the files, your changes will be immediately effective provided your changes do not violate the restrictions imposed by E+C. This is the most efficient work flow.
The heavy-handed approach is to disable Edit and Continue. Tools + Options, Debugger, Edit and Continue, uncheck the Enable check box.
I don't think that there is a way to avoid that. While debugging Visual Studio lock all files to prevent any change on them, including those on other projects.
You can try to open the project which you are interested on with another Visual Studio instance to make changes to your files or open files singularly with another editor.
This doesn't quite answer the OP's question per se, but for anyone who has stumbled upon this page in the same (very frustrated) boat as I am, this might help.
The solution: start without debugging.
It was driving me absolutely crazy that Visual Studio would not let me edit files while the app was running. My typical workflow is:
Make some changes
Run the app to see the effects of those changes
Based on the results, make more changes, etc. etc.
The problem is Visual Studio was preventing me from step 3. It demands that you STOP running the app before you can even make any changes (including to a XAML file or adding a file to the project), which also means that you can't go back to the app to double-check something while you are actually programming it at the same time (which is how I work, bro).
Thank god I finally discovered if I run without debugging it doesn't impose this ridiculous limitation. It's still a pain in the butt if you actually need to debug something you have to re-run the app in debug mode, but it sure beats having to kill the app before it will even let you edit a file.
II'd like to use Visual Studio to break whenever a record is inserted into a certain table, so I can see the values being inserted and the call stack from that moment. Is that possible, or am I stuck with stored procedure debugging only?
Well, since you're using SqlServer, why not just use Profiler? Set a trace, and you can watch the values insert there.... You can set up the breakpoint in Visual Studio, or you can just set it as a transaction that rolls back, then go through the trace to find the values that would have gone in.
If you haven't used profiler before, it's very easy and should do what I think you're looking to pull off.
Depending on how you are writing your code that is actually performing the database inserts, you could set a breakpoint on the function/sub that is being called and step through it to see the values that are getting passed through, but we would probably need to see more specifically how you are actually performing your database operations in your code.
Edit: As has been said, if you stay out of visual studio, using the SQL Server Profiler is probably your best option.
More effort than it is worth but is possible, could prob create a trigger on the table and use this method http://support.microsoft.com/kb/316549
But like everyone is suggesting, break on the .net code that does the insert or use sql profiler is much, much easier and reliable.