I have a .net 1.1 project in VS.Net 2003 (using C#) in which I can set a breakpoint in one method, and step through code just fine, but when I hit one specific method (which we also wrote), the breakpoints and code pointers go "whacky", for lack of a better term. If the breakpoint is on line 100, the execution pointer stops on line 101. The syntax highlighting that colors the breakpoint red will still be on 100, but it will only be as long as line 101 is (which is to say, shorter than line 100). As you F10 through the code, the deviance between where the code is really executing and where the execution pointer is placed appears to get bigger. Has anyone ever encountered this type of problem before, and if so, what might be a solution to resyncing things so I can accurately debug my program?
Yes. Your debug symbols (.pdb files) are out of synch with the actual code. Close Visual Studio and delete the "bin" and "obj" folders from all of the affected projects. Then reopen Visual Studio and rebuild. This should resolve the problem.
Found it... my PDB files got out of sync with the DLL files... cleaned the /bin/ folder and rebuilt, and the problem goes away.
Thanks me. :)
Related
I recompile my solution, and when it starts in debug mode I get this warnings around my breakpoint saying that it won't be hit.
There is a copy of the source code file that is different.
Why would there be multiple versions of my source code loaded when trying to debug?
I even do a clean compile and still get this error.
Visual Studio is usually pretty good at detecting when your source code doesn't match the code signature of your attached exe or dll process. So I suspect that it is one of two possible issues:
Your debug session's Platform/Configuration (e.g. Debug/x64) doesn't match the .exe or .dll compiled architecture. OR
What you think is a "clean compile" isn't really clean.
The only source code that Visual Studio knows about is the one in front of you. But when Visual Studio is debugging an .exe or .dll, it is attaching itself to the .exe or .dll process, using reflection, and analyzing the code of that .exe/.dll. It determined that your .exe/.dll doesn't match the Platform/Configuration you wish to debug, or its reflected source code doesn't match the written code that is in front of you in Visual Studio's IDE.
When you say that you do a clean compile, make sure that it is really really clean (don't rely on the Visual Studio "Clean" feature. It's not reliable in all cases. For example, if you have created Build Events that copy contents pre- or post-compile. Instead, delete your project's /bin and /obj folders, then recompile. That will ensure your binaries always match your latest code for debugging. Do this a few times, and see if you still get the issue.
I had same error in VS 2019 .I solved that way;
Tools->Options->Debbuging->General and "Require source files to exactly match the orginal version" deselect that option
I'm having a weird problem where breakpoints that are currently hit are not fully highlighted, which causes them to be only partially evaluated. See image below. The statement the debugger is on returns true. However, the debugger does not go past 'products' and thus it goes to the end of the if statement. It can happen to any line of code regardless of length. Also, the point at which the highlighting drops off is random, sometimes it will only highlight the first letter.
Example:
I use Attach to Process (on all w3wp.exe instances) for this project. When not debugging the whole line is highlighted as it should be.
I have tried the following:
Clean & ReBuild Project
Deleting bin & obj folders and restarting VS
Deleting all breakpoints and resetting one or two
Restarting computer
Deleting .SUO file
Trying the solutions in this somewhat-similar topic
I'm not sure what I'm missing here.
This happens when Visual Studio is stepping through compiled code that does not match the source code displayed in the IDE. Among other things, the generated pdb tells VS how long an individual line of code is in order to properly highlight it on a breakpoint; the "incomplete highlighting" indicates that VS is executing a line of code with a different length than the actual line indicated. You need to completely clean and rebuild everything. I know you indicated that you tried that, but something is persisting or not being built correctly.
You can also try going to Debug > Options and Settings, checking "Require source files to exactly match the original version", and building/running again. This should be additional confirmation that there is a mismatch between what you're looking at and what's being compiled.
EDIT: When I run this code in Visual Studio 2013, the debugger is showing Utc, not Local. It's a bug in Visual Studio 2015 Debugger.
EDIT: Have taken the code and put in stand-alone console app, but cannot reproduce in either version of VS. Bummer.
Can someone explain to me how what you see in this screenshot is possible?!
On line 298, endingTimePeriodStartDate is redefined as its Date value but set to DateTimeKind.Utc.
On Line 300, if endingTimePeriodStartDate is not actually DateTimeKind.Utc, an exception is thrown.
The debugger breakpoint on line 305 is hit, meaning the exception on line 302 was not thrown, meaning endingTimePeriodStartDate.Kind == DateTimeKind.Utc
(I also did a System.Diagnostic.Debug.WriteLine(endingTimePeriodStartDate.Kind) before line 305 and it prints “Utc” in the Output window).
When I look at endingTimePeriodStartDate in the Locals and Watch debugger windows, and when I mouse hover over the variable, the Kind property shows DateTimeKind.Local
Usually the debugger will show wrong line numbers, and go into old code if it is running a different version of the dll (a former version) than the one that your code is showing. This happens
when there is some kind of caching
when the former running version wasn't closed correctly, or is still running in another process.
when the Visual Studio is not pointing to the correct code
Usually to fix this, you should:
(Start by trying only a "clean" and "rebuild")
Stop all running or debugging Visual Studio projects.
Close all your Visual Studio solutions and windows, so that Visual Studio is not running.
(If next step doesn't do the trick, then the next time around reboot your computer as well before going on to next step)
Re-open only the solution you need to run. Hit "Clean solution". Then "Rebuild solution".
Check if this fixed the problem.
Manually delete the bin folders: (if the clean/rebuild didn't work)
5.1 If your afraid, backup your whole source directory. After everything works, delete the backup...
5.2 manually go into the dependent projects (that are referenced in your "wrong code showing" project) and in each one of them, go into the obj and into the bin folder and delete everything that was automatically created from there - in other words, everything that you did not put there manually. Usually that's everything. Don't worry, visual studio will re-create the Debug and Release directories and fill them up.
Delete the obj and bin of your project as well.
Rebuild everything.
I keep getting the same message whenever I right click a scenario and "Generate Step Definitions" or "Go To Step Definition".
It worked the first time I tried, but it hasn't since.
I've filed a bug report, but in the mean time, anyone know how to solve this?
Over five years later and I'm getting the same problem... Here is the solution that worked for me:
Close the solution in Visual Studio.
Go to your temp directory in Windows Explorer (enter %temp% in the location bar).
Delete the 'specflow-blah-blah.cache' file.
Reload the solution in Visual Studio, rebuild the solution and give SpecFlow a bit of time to sort itself out.
ive gotten this issue before, we have about 800 SF tests in one of our projects and when we first load it can sometimes take quite a lot of time for it to load up. For me its always sorted itself out eventually.
Another thing to try would be to upgrade to 1.9 which came out a few days ago, it may have improved performance.
Although I'm using the last (1.9.2) I had the same problem. Re-opening VS2010 solved the issue.
I've found a work around for this problem; close the solution and delete the .SOU file. Re-opening the solution then re-creates this file and the SpecFlow context menu options then work.
I got the the same issue when I moved external assemblies to specflow.json file from app.config
1) Turned out that I got an assembly reference which didn't even have specflow nugets.
2) I renamed one assembly, but for some reasons the old name wasn't replaces in AssemblyInfo.cs file. I changed it manually, cleaned the project. Cleaned the specflow cache (see previous answers how to do this) and it worked.
So, check if all the references and assembly names are correct.
Cheers
P.S. Don't forget to setup "Copy to Output Directory" option for specflow.json :D
If you are still unable to force the steps to bind, but just need to get to the definition of a given step:
Place a breakpoint on the first step of the scenario
Debug test
Step into the function (F11 by default)
There you are! VS navigation may not work but the debugger knows the way:)
I get this may not be a direct solution to the original issue with steps not binding, but I think it gets where the OP wanted to go...
The root cause of this issue is your code has poor performance and that cause the slowness and hangs your Visual Studio or due to low performance of code Visual studio moves in unresponsive state.
The solution is improve the performance of your code. You need to optimize your code in all the possible ways:
Use less inputs in each step
Use less parameters in your parametrized methods
Avoid unnecessary loops
Divide the number parameters into more methods if taking more than 5 parameters. It will improve the performance.
Divide the input values into more sub-step or separate steps, it will improve the performance and speed of the code.
Use switch case instead of if else statements if there are more cases.
Free up the occupied memory if the reference variables or objects are no more of use.
Read data from external sources and store them into objects or lists locally and minimize make it one time read from external source once and access the values copied locally in the lists or any other objects/variables.
Close or quite the external files or call to them after use.
Hope this is the best way to improve the performance of code and this issue will not happen for sure and your steps bindings and definition will be more smooth and easy.
We fixed it like this:
close Visual studio
Deleted the obj and bin folders under the project(s),
open Visual studio again.
rebuild
After that the .feature files "came back to life"
I'm working in VS 2008 and have three projects in one solution. I'm debugging by attaching to a .net process invoked by a third party app (SalesLogix, a CRM app).
Once it has attached to the process and I attempt to set a breakpoint in one of the projects, it doesn't set a breakpoint in that file. It actually switches the current tab to another file in another project and sets a breakpoint in that document. If the file isn't open, it even goes so far as to open it for me. I can't explain this. I've got no clue. Anyone seen such odd behavior? I wouldn't believe it if I wasn't seeing it myself.
A little more info: if I set a breakpoint before attaching, it shows the "red dot" and says no symbols loaded...no problem...I expect that. When I attach and invoke my .net code from SalesLogix and switch back to VS, my breakpoint is completely gone (not even a warning that the source doesn't match the debug file). When I attempt to manually load the debug file, then I get a message that the symbol file does not match the module. The .pdb and the .dll are timestamped the same, so I'm stumped.
Anyone have any ideas?
Thx,
Jeff
I saw this functionality in older versions of VS.Net (2003 I think). It may still exist in current versions, but I haven't encountered it. Seems that files with the same name, even in different directories confuse VS.Net, and it ends up setting a break point in a file with the same name. May only happen if the classes in the file both have the same name also. So much for namespaces I guess.
You also may want to check your build configuration to make sure that all the projects are in fact building in debug mode. I know I've been caught a couple times when the configuration got changed somehow for the solution, and some projects weren't compiling in debug mode.
Kibbee, you were right! It was two files with the same name in different folders. I was setting the breakpoint in the correct file on line 58 - it was putting the breakpoint on the other file at line 58. I was finally able to set a breakpoint by using the "Debug-->New Breakpoint-->Break at Function Name" menu option and entering my function name. It stopped exactly like it should have then.
I agree - so much for namespaces, right? Damn thing cost me a couple of hours. Oh, well...at least it's solved and I know why.
Thx for the answer and thx to Matt for his reply, too!