可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效,请关闭广告屏蔽插件后再试):
问题:
I'm not sure what I did, but all of a sudden, my Visual Studio 2012 will not debug any tests.
If I select a test from the Test Explorer and tell it to run, it simply outputs this in the Test Output window:
> ------ Discover test started ------
> ========== Discover test finished: 29 found (0:00:01.3371755) ==========
> ------ Run test started ------ Process with an Id of -1 is not running.
> ========== Run test finished: 0 run (0:00:01.4711861) ==========
what the heck does that mean?! After doing this a few times, the error changed to:
The Operation was Cancelled
which I sure didn't do.
It's doing this on every test in the list.
however, I can RUN the tests no problem, and they pass... but I cannot debug the tests.
What might I have done? I did not actively go into any settings and change anything, perhaps a stray click somewhere, but where?
回答1:
I encountered this today. I tried closing the solution but it didn't work. My mistake I set my solution to Release Mode instead of Debug Mode. I set it to Debug then it worked as expected.
I'm using VS 2015 professional.
回答2:
I was getting the same output after upgrading a test project from VS 2010 to VS 2012 Ultimate Update 3. The message was displayed in Test Output window after using MSTest command to Debug Selected Tests.
I tried to debug tests using Resharper 8 Unit Test Session window. The message in the result window was "Test wasn't run".
The solution that helped me was to modify the test project settings to enable native code debugging as instructed at this link: Uncaught exception thrown by method called through reflection
In case the link does not work:
- Go to the project right click and select properties.
- Select 'Debug' tab on the left.
- Go to ‘Enable Debuggers’ on the bottom
- Check ‘Enable Native code debugging’ (or 'Enable unmanaged code debugging', depends on version) check box
Thanks to GalDude33 for posting the solution.
回答3:
Have regularly the same issue with Visual Studio 2012.
Solution : close the current solution and reopen it.
In my case closing and reopening VS was not necessary.
回答4:
Please follow below steps. It worked for me
Steps.
1.Close your visual studio instances
2.Clean you temp files and prefetch files.
3.delete the files in project bin folder.
4.Restart the applications.
回答5:
Async Tests -
Symptoms in my scenario were similar in that my test was not executing and my breakpoint was not getting hit. The Test Explorer in Visual Studio could see the test, but I could not debug it. Running it acted as though it could not be found even though it could be seen in the Test Explorer.
In case it helps someone else, my issue was as simple as having to change the test method's signature from "async void" to "async Task".
Do this:
[TestMethod]
public async Task CorrectlyFailingTest()
{
await SystemUnderTest.FailAsync();
}
Not this:
[TestMethod]
public async void CorrectlyFailingTest()
{
await SystemUnderTest.FailAsync();
}
回答6:
I was having similar issue in VS2015. Only one unit test could not be debugged in my case. Debugger would initialize a test, but would not debug test itself, nicely exiting.
The problem was in Resharper importing Newtonsoft.Json library without enabling NuGet package for the project. (I used Alt+Enter to automatically import the library)
Solution was to install Newtonsoft.Json NuGet package for test project.
回答7:
Ensure your test project is part of the projects to build.
- Right click your solution from Solution Explorer
- Go to Set StartUp Projects..
- Click on Configuration Properties and ensure your test project is checked for build
回答8:
As of Visual Studio 2017 (15.8), this can happen when the Live Unit Testing feature is active. There's no clear message in the output; it just starts and stops without debugging. The solution is stopping the live testing so then you can debug the test normally.
回答9:
In my case, my symbols weren't loaded.
I had to go to Tools -> Options -> Debugging -> and select "Load all modules, unless excluded" for breakpoints to get hit.
回答10:
Take a look at the following link there is an update that fixing it.
Visual studio 2012 update 3.
http://social.msdn.microsoft.com/Forums/vstudio/en-US/e96f53c7-dc8c-4274-8756-eb745de701e8/visual-studio-2012-update-3-cant-debug-unit-test
回答11:
When I use Visual Studio 2012, for some reasons, if I use shortcut ctrl R+T, it will hit the break point. But if I click "Run All" or "Run Selected Test" on Test Explorer, it won't. Visual Studio 2013 works fine both ways though.
回答12:
For me, update Nuget package of MSTest.TestAdapter
and MSTest.TestFramework
to latest version solves the problem.
回答13:
I was unable to attach to my debugger because it was looking for test settings file.
If this is your issue then go to Test->Test Settings->Uncheck Local.testsettings option
回答14:
None of the proposed solutions worked for me. What worked for me is changing the unit test project and all dependent projects' platform target to Any CPU instead of x64 which is some kind of a workaround not a real fix !!
EDIT
The target platform for a unit test project could be changed from test settings not from the project's properties. Refer to this answer for more.
回答15:
For me the problem was that my config file (app.config) didn't have the Debug Transformation file (app.Debug.config), once I added it start working/debugging again.
回答16:
Hitting "Run tests" will not trigger the brakepoints.
To debug your code and stop at a breakpoint in a test:
Right-click > Debug Tests
or
"Test" tab > Debug > All tests
回答17:
For me the problem was that after upgrading to 2017 v15.5.7 my solution's properties got changed somehow. Which made it where I could run the test once in debug mode, but not again, unless I restarted VS, then it would work again, once. Once I set it back it worked again. The setting was, and should be, for me, Solution > Common Properties > Startup Project > Multiple startup projects. Somehow it got set to "Single startup project".
回答18:
Check that the test project and the main project are using the same framework version.
回答19:
Solution:
Select 'Debug Unit Tests' or 'Run Unit Tests' instead of 'Debug Tests' or 'Run Tests'.
回答20:
app.config problem references can unwittingly cause the debugger not to attach and breakpoints not to be hit when debugging test projects. This file may have been updated by packages or has gone out of date.
Solution: I generally copy then remove all dependencies under the runtime tag from the test project's app.config. Debugging usuually starts working after this but some references may need to be added back if assemblies can't be found.
回答21:
In my case, the break point can't be hit if there is build warning(s).
I can verify this by toggle the line of code with warning. It was a unused string with length 66000.
(Warning CS0219 The variable 'XXXXXXX' is assigned but its value is never used)
I guess the compiler removed this line so the symbol mapping failed?
回答22:
This might not be a solution to your problem specifically, but I also couldn't debug a test that I had written. Turns out the solution was quite simple:
Change the method from private
to public
. I don't know why debugging isn't possible within private methods, but it's probably got something to to with the [Test]
attribute's implementation. Hope this helps anyone struggling with a similar problem in the future!
回答23:
For me the following worked:
- Close Solution
- Close Visual Studio
- Delete the contents of
"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET
Files\"
- Delete the contents of
"C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET
Files\"
- Open Visual Studio
- Open Solution
回答24:
Saw this post while investigating the same issue; This solved it for me (posting this in case others encounter the same):
System: Windows 7, 64 bit on Intel i5
Actions:
- Downloaded VS2012 Update pack 4 from Microsoft
- Set the UAC (press Windows key, enter
UAC
) to Default
- Uninstall Update pack 4
- (Mandatory) restart
- Set the UAC to Default again (somehow it got reset to none)
- Install Update pack 4
The UAC thing was something that was mentioned somewhere else, but I don't know if this was a necessary step.