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.
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
My program worked fine up until 30 minutes ago when it just would not launch. I didn't change any code and all settings are the same. When I try to launch my application through visual studio it just does what it usually does then says "Ready". Nothing shows. If I try to debug the code by breaking it somewhere, the breakpoint says "The breakpoint will not currently be hit. The source code is different from the original version." Also visual studio freezes if I leave the supposedly running program going for longer that about a minute, then I have to end the visual studio task. There really isn't any code that I can show you for this.
What is going on and how can I fix it? Is my project corrupt somehow?
If this happened to me I would do:
Check Configuration ( Debug vs Release vs other)
Check Platform (AnyCPU or ....)
Make sure that they both are Debug and AnyCPU
Save solution
Clean Solution
Build each project starting with the one that has no dependencies
** UPDATE **
You posted this message
"0 succeeded, 0 failed, 1 skipped" –
When you Clean, there should be no skipped projects in the process of rebuilding
i recently installed VS 12 Service Pack 1.
Since then, i noticed Visual Studio doesn't compile my project on start if changes were made.
Normally if you start (debugging) a project which has some changes, it recompiles it and starts then. But now, i always get debugging errors like "this breakpoint can´t be reached, because the source code is unequal to the runtime code" or whatever.
It´s annoying to recompile it manually always before starting - I always forget that :-/
Is there any option to fix this?
Can you check if the build on run option is set?
You will find it under Tools->Options->Project and Solutions->Build and Run.
I dont have a good answer as to why this would have been flipped just via installing the update1.
I think that you should enter the Solution's Property Pages (by right clicking the solution in the Solution Explorer pane) and setting the 'build' check-box of the relevant project.
I've checked out a tag for a Visual Studio 2008 project into a new local folder. (The local folder is different than where I normally work on HEAD code.)
I did a 'clean' and 'rebuild' on the project -- which created a DLL file. It rebuilt successfully and is located in the correct build area.
When I look at the files in Solution Explorer, it shows the correct absolute path for all the files within the new folder.
The problem is that when I set a breakpoint and try to debug the code, it never hits the breakpoint. When I right click on the breakpoint and look at 'Location' it shows me a path to where the file had been in the HEAD area when it was uploaded into SVN. I don't see where it is getting that old path from.
Here's a small checklist of things that can go wrong:
Verify loaded Modules (Ctrl + D + M usually). See that your code modules are loaded from where you expect them to load.
When doing clean/rebuild, only the project's output is cleaned (if I have MyAssembly project that builds a MyASsembly.dll, only the file relevant for this project will be removed. Any other assemblies that are referenced are not deleted in the cleanup process.
Try to isolate the issue. Start debugging with F10 (step into the debugged code). See if the entry point is OK, but only some other code that you're trying to hit is taken from the wrong location.
After firing up the debugger, it might help to use menu Debug -> Windows -> Modules to see exactly where Visual Studio is loading the assembly from.
Also, verify that you are building in Debug mode. I hate to admit that occasionally I build in Release mode and then wonder why the debugger does not stop at breakpoints.
Visual Studio editor does not understand unix style end of line. try to use unix2dos util on the misbehaving source files.
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. :)