This seems to be a similar problem like Visual Studio "Debug Unit Test" fails to hit breakpoints
But his fixes didn't work for me.
VS2019 Professional, XUnit:
I'm programming a server backend with controllers, I setup a new project for the test file and used one of the xunit templates, i got some intergration tests with a fake client for my server tests.
All worked fine at the beginning and at the point i set up a client, my debugger started to refuse to hit my breakpoints.
So, you press debug tests, it seems to debug, and after it ran through your tests(successful), it quits debugging. But my breakpoints in every testfile, in every constructor and mehod, were not hit.
they aren't white with red outline, they're normal full red circles
repairing vs didn't change anything
cleaning and rebuilding didn't change anything
my normal project is working and is able to be debugged correctly
I deleted my whole code in the project and had an empty constructor, which breakpoint wasn't hit (no connection to the main file)
Its Debug Version, not release version
updating all nuget packages isn't helping
restarting vs and the pc is not helping
no warnings or anything
setting the testproject to be the startproject didn't change anything
same problem on other devices
If you add more tests, you debug without hitting any breakpoints longer, because yor tests take longer & your tests give the correct result. Therefore I'm quite sure, it's really going past your breakpoints, because I mean, you got the results of the methods you trying to debug.
Add a reference to the nuget package xunit.runner.visualstudio to your test project and try again.
Related
I am trying to set a breakpoint in JetBrains Rider, but the debugger isn't breaking.
I know for sure the application should reach the code I'm trying to break on, as changing string literals appears in the program.
I have completely reinstalled all my JetBrains programs (wiping settings). I've also tried every answer in this thread: break point is not hitting while debugging, with no luck.
This bug doesn't occur in Visual Studio, but does occur with any project in Rider.
It also doesn't happen on my other copy of Rider that I use on my other PC.
I appreciate any help, thanks!
One more caveat: I started using Rider again after an absence, I was pressing the "play" (triangle) button rather than the button with a picture of a bug.
(D'oh!)
For .Net Framework projects:
This can happen if Rider attached the debugger to a different process than the process that IIS is using.
Open Run on Rider menu and click on "Attach to process" or ctrl+alt+F5
Type w3wp, this will find all the processes IIS is running on. If you found multiple processes you can hover on them to see which AppPool is related to that process.
Click on the process to attach debugger to it.
The breakpoint should be hit now.
And make sure you are using the URL that Rider provides you when you run your project (http://localhost:XXXX), because the URL that Rider uses might be different than the Host Name you set for your IIS.
I've found what was causing it.
As of Rider 2018.1.3, the solution you're running must be on the same disk as the copy of Rider you're using.
This issue is referenced on JetBrains support here.
You can temporarily solve this by either moving your solution to the same drive, or by reinstalling Rider.
What I did before was :
Open the solution
Set some breakpoints
Click the 'bug' button in Rider (next to the play button)
Chrome would open up automatically with an URL pointing to my services
The service would work as expected, but breakpoints would not work
Stop the service
Modify some code
Start the service
Refresh the Chrome Windows from step 4
I would see the modifications in Chrome. But no breakpoints would get hit.
Now the only thing I changed is that in after step 2 I now do a
Run --> Attach to a local process... --> w3wp
After this, I just do the same steps as before, but now the breakpoints do get hit...
Refrence
For anybody who has the same problem in Xamarin Android project.
For me the breakpoints in the android project where working, like in the main activity but not in the shared project.
How i fixed it:
Go to your android.csproj file and edit it. Search your build target and check for <EmbedAssembliesIntoApk>true</EmbedAssembliesIntoApk>
If this is true, breakpoints in additional modules are not working.
Set it to false, or even better, remove this line completely.
In relation to Jessica's answer above, it appears that opening a solution in Rider using the System absolute path (i.e. /System/Volumes/Data/Users/...) appears to act as though it's on a separate drive.
After driving myself crazy for about four hours, I created a new solution and changed the solution directory from the system path to /Users/... then copied my project to this new solution which fixed the breakpoints, and opening the project from the Rider welcome screen now shows the solution directory as a relative path (~/Users/...)
Another solution for you (or other people who come across this):
When you have "COMPlus_EnableDiagnostics": "0" in your configuration or launchSettings you won't be able to hit breakpoints either.
Cleaning and rebuilding the solution, and then removing and readding the breakpoint worked for me!
None of these solutions worked. Solutions of clearing caches through the Rider interface and stuff like that, none of them worked. None of them.
The problem: a previously working referenced project of custom code (not some external library or nuget package) broke the breakpoints. Breakpoints outside the package worked, but not in the referenced project. I was getting that "stop sign" symbol in which it couldn't resolve a method.
The only thing that worked was to completely erase all instances, and previous instances, of Rider from Application Support and Caches on my mac. After following the instructions to completely erase Rider on their website, and then reinstalled it, I was able to get the breakpoints working again. Sorry, but for some of you this may be the only thing you can do.
If you're using .NET core and IIS, make sure the Application pool has 'No Managed Code' under '.NET CLR Version' in the Basic Settings:
I had this problem too and the cause was a spurious <ContinuousIntegrationBuild>true</ContinuousIntegrationBuild> in the csproj. Removing this setting restored debugging capabilities.
In my case the breakpoint not being hit when debugging a project with IIS Express.
The issue has been solved after running Rider as administrator
Thanks to #David smith's answer here:
Can JetBrains Rider work properly with IISExpress?
I am using VS2015 and have a C# / ASP.NET webforms project which is working well. However, now I am needing to add new syntax and test it, so I opened it and set a few breakpoints, but the code is not stopping on the breakpoints! I opened both webconfig and Webconfig and they both have debug=true I also tried to re-build my project from the build menu and this did not solve it either. So what else should I do to get debugging working?
EDIT
and yes I am set to debug configuration, see image
Make sure that in addition to setting debug in Web.config that you've selected the DEBUG configuration for the project in Visual Studio. Look for the dropdown box in the toolbar that has Release vs. Debug. If it wasn't in Debug, rebuild all after that and confirm you still have zero errors.
Then make sure you are attaching the debugger. If your web project is the default, then the little green arrow next to the debug/release dropdown will launch a web browser on your site and (critically) attach the debugger. As long as you keep that browser instance running, the debugger will stay attached and you'll hit breakpoints even when someone else and/or another browser hits your site.
Finally, be aware that without some special tricks, it is very hard to hit breakpoints in Global.asax:Application_OnStart because this code runs before the debugger has a chance to attach. You can add trace statements in there and then view them after the fact though.
Posting this since it seems to have been the answer
I usually see this happen when the IDE is running from an old copy of the assembly. For instance, if you had two branches of the same project open and built... sometimes your changes aren't caught as being changes so you end up running on an old build. I'd shut down every other instance of VS, clean the current instance then shut that instance down. Make sure IISExpress is also shut down (check the tray). Then start it back up and try again
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 have a console application and I added a class library solution to the project to hold all my unit tests.
All is working fine apart from the fact that breakpoints do not get hit when I run my tests.
If I run the whole application, breakpoints on the console app get hit fine.
If I run the tests, breakpoints in the test classes and the console app are completely ignored.
I saw another post saying to go to debug > start new instance, but as it is a class library I cannot do this. Should I have test classes in a different project type?
I am using Nunit, VS2012 and the NUnit runners.
I have a couple of tests failing and I cant figure out why, I really need to be able to step through the code.
Any help is greatly appreciated.
Instead of running your tests, try debugging your tests
For anyone else having this issue: check if you are building in Release mode.
I had this problem with NUnit 3.7.0, and dotnet core 1.0, and VS 2017. It turned out that I was building in Release mode. Building in Debug mode fixed the issue.
My test code was compiled in .Net 4.5 and was using the Nunit2.6.1.
The breakpoints were not getting hit if I had only made the test project's debug option->start external program->nunit-86x.exe and give the .dll name to be the command line argument.
This starts off the Nunit exe but without breakpoints.
1) To solve this go to
C:\Program Files (x86)\NUnit 2.6.1\bin
2) Search for nunit-x86.exe.config or if you plan to use the nunit.exe then open nunit.exe.config.
3) Open the fine in notepad and search for the line
<startup useLegacyV2RuntimeActivationPolicy="true">
<!-- Comment out the next line to force use of .NET 4.0 -->
<supportedRuntime version="v2.0.50727" />
<supportedRuntime version="v4.0.30319" />
</startup>
4) Remove the line of supported Runtime version=v2.0.50727 and save the file(open in administrator mode by opening notepad in admin by right click and open as admin).
5) Rebuild project the run your test code's debug session. The breakpoints will be hit.
In my case a line of code seemed to execute a never-ending loop, which made it impossible to reach the breakpoint.
Solution: Put a breakpoint in the beginning of the debug method in order to check for this error!
This is happening to me very often. When I am working in Visual Studio 2010 and say I make a code change, then build... Both my existing breakpoints become disabled / and or cannot be set and I also cannot set new breakpoints. Does anyone have a solution for this? It is very annoying. So far the only way I have been able to get around this is to restart Visual Studio which can take 5 to 8 minutes to reindex everything or to try rebuilding individual projects in my solution. My solution consists of several DLLs which make up the entire program.
Check that you have the dependencies set correctly in your projects. I know my breakpoints will become disabled if the code is "out of date". If you don't have the dependencies set up right, then when the updated code is rebuilt it will not rebuild all of the related code which will then leave those modules "out of date".
Since this is VS 2010, the dependencies are on the project not on the solution (you can add solution dependencies, but project dependencies will carry over into a new solution so it is the better way to go when possible).
This issue is caused when you having your Configuration Manager settings set to Release rather than Debug.
In Visual Studios select Build from the menu, then Configuration Manager.
In the next dialog select your project, then locate the drop down menu near the top left corner titled "Active solution configuration:" Make sure it is set to Debug.
That should fix the problem.
As it turns out the post.build file contained numerous conditions for whether or not it should copy several DLLs to a target directory... Since I didn't have time to pick through the xml for these actions I just used a bash script to copy the files after building. No need to get complicated... Otherwise, the formal solution involves setting conditions for allowing the DLLs to be overwritten/copied after compile or not.
I find the Visual Studio post.build file concept a little excessive since in the end it will make little difference whether a dll is overwritten with a freshly compiled version, yet, if you make code changes, compile, and it doesn't copy to the target directory you end up running your app with an out of date DLL and you are not testing with the recent code change..! Others have even implemented the post.build file complete with xml and goto statements...! Leave it to Microsoft to complicate the build & debug process...
Alternatively, if your code is under version control start afresh by checking out the head revision, do another clean and rebuild and start debugging again.
This for whatever reason enabled me to insert breakpoints in my VS 2010 C# project once again, whereas no amount of fannying around with properties, configurations etc got rid of my phantom breakpoint problem.
The best solution I found for this was to quit my Windows job and get another job as a Mac Developer where we use Xcode.! What a huge difference.! I sure haven't seen that breakpoints problem again.!