So ive done developing on Visual Studio before, and normally I can step into my program the whole way through and see what it is doing in the more localized area. i.e. it will only step through the main function. I took a break from coding for about a month and I guess they updated something.
Basically, every time i step into just about any line, it will go through the xstring or xmemory file forever before returning to the program i wrote for 1 line, then doing the exact same thing again. Looking for a fix to this so i can get it back to how it was before. Thanks!
Related
For some unknown reason, my visual studio adds many break marks in my code.
Some where I believe i had some in the past and some in utterly nonsense positions.
I have found nothing in the web. Dont know if thats a bug or if I am using it incorrectly.
Anyone had that before or knows how to resolve this?
I can remove them point by point until my app runs through but as soon as I start debugging, they are beeing readded. When I stop debugging, they are gone again. I was even able to capture one sample beeing added:
It litterally makes debugging impossible. I cant remove 50 break points whenever I want to debug...
Workaround #1
I have found kind of a workaround by going over Debug -> delete all Break points.
Be aware, this will delete your wanted breakpoints as well.
I have a .NET Core 2.1 solution containing 2 F# projects, one class library and one executable. When I run the executable project with the command:
dotnet run --project ServerProject
it shows the Suave.IO log message immediately:
Smooth! Suave listener started in 92.632ms with binding 0.0.0.0:3000
However when I try to debug in Visual Studio (2017 or 2019 Preview) nothing appears on the dotnet.exe window at all — unless I pause debugging and continue, at which point it will carry on as usual and display the log message immediately.
I have set breakpoints to try and figure out where it gets stuck but nothing special happens there at all. My code loads some data from a CSV and it somehow gets stuck at the stage where it converts the CSV's rows into some records. All breakpoints and printf statements before this function get hit but the subsequent ones don't. And every time I pause debugging it seems to pause at a different point of this cell parsing code, so it's not even hanging in the exact same place every time.
I'm fairly new to the .NET world so I'm not even sure where to start investigating. Any help would be appreciated!
EDIT:
Adding this to say that this has been happening consistently for many months now. Any ideas would be really appreciated.
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
I have a VS macro that I've been using for years to build my projects automatically. I'm currently trying out VS 2010 to see if I like it (my regular version is 2005), and one segment of the macro is not working in 2010. Well, rather, it will work ONCE on a given day, and then every time I run it after that, it fails. Here is the code:
With DTE.Solution
'Set the Build to "Release"
.SolutionBuild.SolutionConfigurations.Item("Release").Activate()
'Build solution
.SolutionBuild.Build(True)
'Set Build back to Debug
.SolutionBuild.SolutionConfigurations.Item("Debug").Activate()
End With
The line that fails is ".SolutionBuild.Build(True)". It simply doesn't Build the solution. There's no error. No indication that something is wrong. The code will run, but it just doesn't actually DO the build.
Does anyone have any idea why this would be happening?
My experience with it is that it does build.. if needed.
Try a Clean... if you want to rebuild every time.
DTE.Solution().SolutionBuild().Clean(True)
I'm trying to debug a C++ project in VS 2005.
In debug mode how can i find the previous line that got executed.? i.e Consider the control is in line 5000. How can i find the previous line which got executed before coming to line 5000. Actually there are few goto statements involved. Call stack is just displaying the previous functions which were called.
Though i know it is not a good practice to use goto, this is an existing project which I'm debugging. Thanks in advance.
This information is lost. You should single-step in the code or add logging to know which lines were executed.
If you got to line 5000 by a goto or a jump (rather than by a call), then there is no record of where you came from. You will just have to go back and trace through the code and watch it as it jumps to line 5000.
If you can recompile the source (which I guess you can since you've got debug information) you might want to sprinkle the code with calls to OutputDebugString each with a different bit of text - for example before each label and each goto.
That way when your line gets hit you can check which messages got dumped to the output window to find the execution path.