Is this a new feature of VS 2017 that every time I am trying to debug a unit test, and point the cursor at a variable to inspect, VS freezes at first, then throw up this:
And if I hit F10 after this window finally goes away in 10-20 seconds, VS throws up this:
Is this a new normal and expected behavior, or I am missing any settings?
1) Please try to disable the option "Enable property Evaluation and other implicit function calls" under Tools->Options->Debugging->General.
2) Delete all of the breakpoints, reset the one that you want and debug again.
3) Another workaround could be to enable the option: "Use Managed Compatibility Mode" under Tools -> Options -> Debugging -> General, but it will disable Edit and Continue. Reference: Visual Studio 2015 update 3 crashing after "Getting DataTip text..."
4) Btw, the latest update of VS 2017 is 15.5.3, you may also try to update to it.
And of course, you could post the unit test code sample if it’s possible, since I could not reproduce this issue with unit test project in VS2017.
Related
I've used Visual Studio 2017 to create a queue triggered Azure Function. All that the default generated code does is write a message to the log. The code works, but if you set a breakpoint on it, it is ignored by the debugger.
I have same problem with another queue triggered function that has more complex code, but I created this one as a very simple test case.
What do you have to do to get debug breakpoints to work on this type of project?
Answer was found here which is:
(1) right click your project and go to properties page
(2) select "Build" on left
(3) click "Advanced..." button
(4) change "Debugging information" to "Full"
As stupid as it sounds, I managed to make it work by unchecking the option
Automatically close the console when debugging stops
in Tools > Options > Debugging > General
I just installed Visual Studio 2013 Premium and was having a good time playing with it and writing unit tests (using MS unit tests). However, the "Test Lists" window and some other Test related windows suddenly disappeared AND they have disappeared from the menu item
Test->Windows. In fact I remember Test->Windows having 4 items under it and now I only see two: Test Explorer, Code Coverage Results. i stress they WERE present in Visual Studio 2013. Clearly, I hit some key combination that made them disappear or something happened to make them disappear. How do I get Test List back? Please don't see they are under Tests->Windows, because for me, they are not (at least now. they were!)
Anyone else seen this? Any solutions? I tried restarting Visual Studio, rebooting.
Also, previously, under the "Test" menu, there was a Debug->"Test in Context" and a Run->"Test in Context", or something like this. It was very handy. If your cursor was with in some test, you could run just that one. I'm guessing this is related.
For all I know, these features have been "optimized" into the new test-window... a.k.a. they have been removed. Some other unit test related features are also gone (the context menu item for "create unit tests" is gone for example, yet can still be called via the command window)
Personally I think this is Microsoft's way of pushing everybody towards the Team Foundation Server but that's just my two cents.
I just had the same issue. In my case I needed to install the NUnit plugin ("Nunit test adapter"). After restarting the tests came back.
Start Developer Command Prompt:
cd to UnitTest-folder\bin\Debug which contains .dll
enter command: mstest /testcontainer:UnitTestMyTest.dll
(this creates the test-result)
in VS:
menu View / Other Windows / Test Results
manage Test Runs: window Test Runs -> connect to Test Run
browse to test-folder\bin\Debug\TestResults
I've fixed a null reference problem. Now when I run the test related to that class, it fails. I'd like to know whether is possible to run a test in debug mode so I'll know why I am getting the exception?
The test was written by some else, it's calling a method, as part of the setup, with a lot of logic in it. I'd like to step in to see how values are being returned.
Thank for helping.
It is indeed possible, using the NUnit Test Adapter for Visual Studio 2012.
Also, just so you're aware: failed assertions will throw exceptions, causing the debugger to break execution. You can adjust your configuration to work around this, as described in this thread:
Debugging in VS2012 with NUnit without throwing exceptions?
You can also use ReSharper, which makes it pretty easy. Or, you can just go into the properties for your DLL project that has the test in it and make the test runner you are using the exe that runs when you run the project.
Right click the project in the solution explorer, select "Properties" from the menu, go to the "Debug" tab, click the "Start external program" radio button then set the project as the active project and run in debug mode.
When a test hangs in a loop, the small green progress bar in the test runner does not proceed, but there is no way to stop the test run. Or is there?
VS 2013
Edit: This occured when using the XUnit TestRunner. The Cancel button simply did not show up. After testing various test runners in a new solution, it turned out, that it works with all of them. Finally it also worked with my original solution. So there was some anomaly in the state of my VS environment that caused cancel to disapper.
You can click "Cancel" in Test Explorer:
Show Test Explorer by going to TEST > Windows > Test Explorer.
This is in Visual Studio 2013.
Instructions for other versions of VS can be found here
Sorry for waking up an old thread:)
just wanted to share my solution here, I had the same issue on VS 2015.
There is some text below the search input just where the cancel should appear (take a look at #Codeman print screen), the text is actually some description on how you can setup a build for your tests, the text is several lines and at the end you have "do not show this any more" just press it and then the cancel button appears:)
Very strange bug, sorry I do not have some print screens of this
hope it helps someone
VS2015. If the hanging tests are executables instead of DLLs you need to kill those tests in the task manager. You need to close the Test Explorer Window to prevent automatic running. While the tests are running/hanging you will not be able to compile the according project.
For me the solution was to go to Task Manager, locate chromedriver and end the task.
Visual Studio 2022 Professional version 17.2.3.
I have found the solution to this issue. To stop the run after cancel is pressed, just set the 'Terminate process on cancel' option to True.
If I create a new win32 C++ project in VS2008 I can use Edit & Continue with it just fine, but with this legacy project I'm working with my attempts to use / enable it have failed.
Here are things I've checked:
Tools -> Options -> Debugging -> Edit and Continue -> Enable Edit and Continue is ON.
Debug Information Format: Program Database (/Zi)
Code Generation -> Enable Function-Level Linking: Yes (/Gy)
Looked for a corrupt .ILK file. I can't find any .ILK files - are they still used in 2008?
But when I step into the program, change the next line, and step again, I get:
"This source file has changed. It no longer matches..."
rather than
"Would you like Edit & Continue to apply your code changes."
What's wrong with this project that E&C doesn't work?
I assume you have debugging symbols/etc and the legacy C++ application had been compiled with this support...
If not, then you will run into the problem that the code was not 'instrumented' to allow for injection of alternate code.
I would suspect that the changes in output code format would make VC++ 2008 incompatible... as I doubt Microsoft added such backwards compatibility in (until VS 2008, I think they even made it hard to use older versions of .Net without using the specific VS)
This messagebox
This source file has changed. It no longer matches the version of the file used to build the application being debugged.
seems only to be appearing when I made a code change on the exact line where the breakpoint is.
I've found that I can just click the OK button. And when I then press F10 to actually execute the line that has changed, "Edit and Continue" kicks in and recompiles the code.
After that, the breakpoint is disabled though (it shows a yellow triangle with an exclamation mark):
To re-enable it, you can just right-click the breakpoint and choose "Location...":
which brings you to this dialog:
:
where you need to check the "Allow the source code to be different from the original version" checkbox. Click OK and your breakpoint will be enabled again.