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!
Related
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.
I'm attempting to debug an NUnit 3 test from Visual Studio 2017 by using Project Properties -> Debug -> Start External Program = <path to nunit-gui.exe>. I can just use the NUnit Test runner from within Visual Studio--that works fine. I can also run NUnit GUI first, load the DLL, and then attach to the nunit-agent-x86.exe process and the breakpoints work. However, I'd like to just be able to click the "Start" button from within visual Studio without going through those extra steps.
NUnit GUI does start and I'm able to run the test. However, when I set breakpoints in Visual Studio, they don't get hit (mousing over the breakpoint yields a popover with the message, "The breakpoint will not currently be hit. No symbols have been loaded for this document."). In the past, under NUnit 2.6, I fixed this by modifying the nunit-gui.exe.config:
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0.30319" />
<!-- <supportedRuntime version="v2.0.50727" /> -->
</startup>
However, this still doesn't seem to fix the breakpoint issue in NUnit GUI 0.60.
My test assembly platform target is x86 (due to x86 dependencies). I'm running my test on Windows 10 64-bit.
In VS2017:
In the top menu open the Test Explorer window via Test > Windows > Test Explorer.
Rebuild the solution.
Set a breakpoint in the test you want to debug
Left click on the "blue diamond" icon between [Test] and the public void method definition.
Left click Debug.
I am writing tests for an application using Outlook Redemption that absolutely must run 64-bit (it connects to windows MAPI and Outlook x64). Unfortunately, I cannot for the life of me make it run the test in 64-bit. I have tried using a .runsettings file (edited to indicate 64-bit) and a .testsettings file (also edited), and finally I have selected Test>TestSettings>Default Processor Architecture>64-bit, to no avail.
Every time, System.Environment.Is64BitProcess is false, and when I load the dll to connect to Outlook and MAPI I get the dreaded COM Exception: Wrong OS or OS version for application (Exception from HRESULT: 0x800401FA (CO_E_WRONGOSFORAPP)) which indicates that 64-bit Outlook is installed and the process trying to access it is 32-bit.
I have restarted VS 2012 after making settings changes as I have read somewhere that a restart may be necessary. Does anyone have any other suggestions? I could just write this as a console app that runs informal tests and reports their status, but my next step is to get these tests integrated into the automated build. Any help would be greatly appreciated.
Edit
Screenshot of Host Settings page in .testsettings
Experiment
Interestingly, I did a little experiment. I created a new solution with a single console app project. I put a public method in there that just returned true. When I ran the console app, and paused execution, I looked and indeed it is running 64-bit; no problem there. I then added a test project, created a single test which called the method. I also added var is64 = Environment.Is64bitProcess and put a breakpoint after it.
Predictably, without changing any options, is64 was false. I chose the 64-bit default architecture from the dropdown under test, then cleaned the solution, and ran the test again, same result, running 32-bit. I restarted VS2012, cleaned, built, same result. I created a testsettings file and referenced it in the Test menu, clean build, same, restart,clean, build same. I created a runsettings file, set <TargetPlatform>x64</TargetPlatform> , referenced that in the test menu, ran through it all again, and came up with the same results. QTAgent32.exe continues to run the process, and absolutely refuses to heed my demands that it run 64 bit.
I swear, if I have to delete QTAgent32.exe and rename QTAgent to that name, I will. I am not above cramming my wishes down the computers throat when it wants to be obstinate. Please, if you dont want to see me mistreat a workstation, someone show me what is going wrong. Think of the computers.
If you use VS2012, then you will be able to select your platform x64 through test settings as below;
In this example I am referring to .runsettings file.
the settings are
But if wish to run your test through command line you need to use vstest.console.exe instead of MSTEST as it doesn't support for x64 test.dlls
you will find vstest.console.exe at "C:\Program Files (x86)\Common7\IDE\CommonExtensions\Microsoft\TestWindow\"
Please note below steps
Open CMD
Navigate to "C:\Program Files (x86)\Common7\IDE\CommonExtensions\Microsoft\TestWindow\"
execute vstest.console.exe "C:\Projects\Test\Test.Automation.Specs.dll" /InIsolation /platform:x64
Note : Test.Automation.Specs.dll is your test project and you need to define full path
I hope this help
I ran into the same issue just now. Here are the steps you can follow to fix the problem.
Switch default processor architecture for unit tests from x86 to x64: Go to Test->Test Settings->Default Processor Architecture->x64.
Change the Build settings for the unit test project to x64.
Clean the solution then rebuild the solution. Your unit tests should now show up in the test explorer, and you should not run into this issue anymore.
References
Link to MSDN reference which explains how to resolve the issue.
This is a bit out of my scope, but the configuration settings for both projects are set correctly, right? You have them set to build for AnyCPU or x64?
Just trying to Occam's Razor it out... I know I've been frustrated too many times by configuration settings that VS just magically decides to change on me.
I have an asp.net web app, and I have added some related class projects to my solution file. When I run the web app, I want to break and step through the code in the class (when a class is referenced).
I don't get an error messages. The code in the class project just does not kick in.
I have searched and read this post Debugging a Class Library but no luck.
How do I get that to work?
Can you try to stop the ASP.NET process? I usually have this problem when the asp.net service is still running, and I compile (by asp.net service I mean the icon that appears near computer clock). Try to close that, recompile, then run.
Are you sure you have <compilation debug="true"/> set in your web.config file? Are the classes in the same assembly as the rest of the application?
edit: The only other thing I can suggest is stop IIS and/or all instances of the vs development server, clean the project, rebuild, and give it another shot. Also be sure there is only one web.config and you aren't running in release against Web.Release.config or something.
This sometimes happens. Check Debug>Modules to see if there is your dll loaded. It seems that VS debugger doesn't have .pdb file available. Clear Temporary ASP.NET Files in your .NET folder, Clean/Rebuild and try debug again.
Also do not forget to run VS as Administrator. Try to Attach to process instead of F5.
You can call in your code this function, and the debugger will pop-up
System.Diagnostics.Debugger.Launch();
alternative you can call the Debug.Fail("Stop me to see what next");
I'm running a C# program on Visual Studio 2008
It freezes at some point, and when I try to pause for debugging, VS2008 freezes also.
when I close the program console window it pops up a "unable to break execution" message box.
When could be the cause of this?
Thanks
Roey
I get this error when I try to debug a .NET 2.0/3.0/3.5 project with "start external program" and the program automatically loads v4.0. You can easily add an app.exe.config file for the external program with the SupportedRuntime specified:
<?xml version ="1.0"?>
<configuration>
<startup>
<supportedRuntime version="v2.0.50727" />
</startup>
</configuration>
Note that "v2.0.50727" is appropriate for 2.0, 3.0 & 3.5 regardless of service pack.
It's really hard to tell without some more info.
A few things to try:
Try using ADPlus to get some richer information about the hang.
Try running detached and then attaching.
Try running detached and then attach from windbg.
Try disabling all your VS plugins.
I had similar problem running VC 6.
Using windbg didn't help as it also got hanged?!
Eventually I used kd (kernel debugger). Then when the machine hanged, KD immediately reported some driver (a backup tool) had an issue. Disabling that driver got the strange hang issue resolved.
Tal.
I just had a very similiar issue, using Debug -> Delete all breakpoints solved the issue (breakpoints sometimes go rogue unfortunately).