From one moment (not fixed when it happened, probably, when I moved some test projects to another folder on disk) Visual Studio is taking longer than expected when I open Test Explorer and want to run tests. It takes minutes like this:
Why it happened and how to fix it?
Related
Most recently, I decided to reopen and resume a project which ran just fine on the same computer, about a month ago. in the interim, I had decided clean up all the temp files and cache and so on.
Now, when I ran the build, no errors. However, when I tried to run the project locally, visual studio would get stuck at 'loading symbol mscorlib.dll' and not budge. it seems to get frozen if I try to cancel, but not if i just let it be. no other activity on visual studio to see what is happening.
Another project, builds and runs just fine (but the project giving issue has an azure linked database server which is working just fine)
restarted visual studio, no change
Still, no go.
Ultimately, I decided to just let visual studio load for as long as it takes.
After about 20 minutes, it seems to have obtained all the symbols.
Now, successive runs are happening within seconds. So, 'waiting' is simply the solution.
We are in the process of upgrading from Visual Studio 2013 Update 5 to Visual Studio 2015 Update 1.
Our Solution has many tests and we use NUnit 2.6.4, along with the NUnit Test Adapter for NUnit 2.x.
When running these tests in Visual Studio 2013, they all run perfectly well.
However, when running in Visual Studio 2015 the first 200 odd tests run, then execution stops. I can then select the tests that have not yet run and successfully execute these. I have the latest ReSharper installed in both VS2013 and VS2015 and it happily executes all the tests.
We've been keeping test-coverage details for each release since the dawn of time, and from Visual Studio's test runner it shows me the number of blocks covered. But ReSharper shows us the number of statements covered. Slightly different values, but they'd mess up our charts.
When test execution fails, it creates a Dump file (it also creates some XML files that just seem to show what DLLs I've installed). I can open this and "debug" it, but it simply shows me a line of code that fails, and the call stack shows only [Managed Code], which means I can't identify the actual test that's causing the issue.
The fact that this works perfectly in VS2013 and in ReSharper running in VS2015 suggests that "it's not our fault", but whilst I'd like to think that, it doesn't help me fix this.
Any ideas?
Thanks
Griff
Tracked down the problem. We had one class in our Solution that implements IDispose and one of our Unit tests didn't dispose of that class, it just allowed it to go out of scope.
So because the Disposable object hadn't been disposed, the class' Finalizer hadn't been suppressed. The GC therefore called the Finalizer which in turn attempted to access another object that had also gone out of scope, resulting in an exception that crashed the Test Execution Runner.
Interesting that VS2015 running NUnit 2.x crashes, but the identical setup in VS2013 copes fine.
As an aside, when debugging the DUMP file (see above), I realized that the call stack was irrelevant, I just had to put in some defensive coding in the Finalizer.
So my Visual Studio 2010 is extremely slow (and sometimes freezes) when I have a particular file open and attempt to compile and run the project. I have to open the Task Manager and kill the process for Visual Studio to regain control. If I close this file, and open any other file in the Solution Explorer in my project, Visual Studio compiles and runs the program just fine. The build succeeds, but Visual Studio just freezes after that. If I attempt to do anything in the IDE, Windows will tell me that Visual Studio is not responding. I've tried commenting out everything but the bare essentials in the file that's causing the freezing, and that didn't work. In order to get my program up and running, I have to close the file and then build the project. Visual Studio will then build and run the program in a timely manner as long as the particular file is not open. This only started a few days ago, and I haven't made any changes to the code that could have done this, nor have I updated or installed anything else onto my computer. Any ideas would be greatly appreciated. Thanks.
I fixed this. What I did was run devenv.exe /log and looked through the log. It had the following warning in it: "The CTM file is out of date and should be deleted and rebuilt, but the file 'C:\ProgramData\Microsoft\VisualStudio\10.0\1033\devenv.CTM' could not be deleted." I went and deleted this file, and it did the trick. Now even with that particular file open, Visual Studio builds and runs the program just fine.
The Code Lens feature of Visual Studio 2013 won't work anymore. It says "Loading references for this method" but it takes years and actually it doesn't load them for any method at all.
It used to be working just fine but I am not sure why it stopped working. I restarted Visual Studio 2013 many times, I even restarted my computer but no luck.
It is enabled in my Visual Studio 2013.
I will answer my own question as I managed to solve it.
It seems each time you run your tests in Visual Studio, it stores the result of your tests in TestResults folder in the project folder and it was about 800MB in size in my computer.
I just deleted it and clean the project bin and obj folders as well (which I did for several times before and didn't really work). But removing TestResults folder did the magic.
My guess is that because of the humongous size of the TestResults folder, Visual Studio 2013 cannot load all the results etc. quickly and that's why it was taking years to show me Code Lens feature. So delete that folder time to time for better performance.
Here are some results about TestResults folder after I googled it:
How to: Deploy Files for Tests: http://msdn.microsoft.com/en-us/library/ms182475.aspx
How to preserve the test results directory?: http://blogs.msdn.com/b/aseemb/archive/2013/02/23/how-to-preserve-the-test-results-directory.aspx
How to delete Test Results folder:http://blogs.msdn.com/b/ploeh/archive/2006/07/13/cleaningawaythetestresultsfolder.aspx
UPDATE
Even if those methods above may work for you, I realized that they actually fixed this issue since Visual Studio 2013 Update 2. So instead, please update and install it.
In case the the above solution isn't working for anyone else, I had a different fix that worked for me. In my case it showed that I had references, but would not display the details or links about them.
I had to install a new extension to reset a MEF cache corruption. This fixed code lens and the Page '312e8a59-2712-48a1-863e-0ef4e67961fc' not found error.
http://www.hjerpbakk.com/blog/2014/7/25/no-content-in-solution-explorer-using-visual-studio-2013
I found out that if you block the Visual Studio with the Firewall, the Code Lens did not work.
So unblock it from the firewall to make it work.
CodeIndexing must be enabled on the TFS Server. You can check this setting using TFSConfig:
TFSConfig CodeIndex /indexingStatus /collectionName:"YourCollectionNameHere"
You can start indexing with:
TFSConfig CodeIndex /setIndexing:on /collectionName:"YourCollectionNameHere"
I am using Visual Studio 2005.I am running my code in Debug mode only.But my break point is
not being hit.
I followed :
Cleared my solution and created the one again
Closed the VS and Opened it again
Restarted my PC and tested the break point
But i am unable to figure out the problem.
My Question is:
Is it due to any virus ?
Add-on feature in my IE 8.0 prevents this
My VS is Corrupted ?
I am having botn VS 2008 and VS 2005 installed in my machine so any version
conflicts?
Suggestion is needed.
It sounds like the problem you are having may be due to the source code and the .pdb files being out of sync with each other.
Try these steps:
Perform a "Clean" build in Visual Studio.
Shut down Visual Studio.
Delete any "bin" and "obj" folders in all of your project folders.
Delete the solution .suo file
Sometimes the solution .suo file can become corrupt (doesn't cause Visual Studio to indicate any errors, but usually leads to strange behavior). Nine out of ten times, deleting the .suo file clears any strange behavior in Visual Studio.
The trick about deleting the "obj" folders forces Visual Studio to truely do a clean build the next time it compiles. Doing a "clean" build in Visual Studio only deletes the compiled binary results, it doesn't remove any intermediate object files that may have been created that Visual Studio might be linking against. By manually deleting the "obj" folders, you delete those cached object files and force a true rebuild.
What kind of project is it (website, console app, ...) Are you running the project directly from visual studio, or attaching to it afterwards?
Usually when this happens to me, its because the assemblies that are being used to run the process I want to debug do not match the currently built assemblies from visual studio.
You mention IE8, so if this is a website, you should try to attach visual studio to the w3wp.exe process. Otherwise the breakpoint won't have any effect. Alternatively, run the website using visual studio.
If you hover over the breakpoint in Visual Studio, does it indicate an error? Common problems are that the code hasn't been built, or the DLL that contains the code isn't loaded into the debugged process.