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"
Related
I am working on a c# code for the last couple of weeks and I debug it very often.
VS 2019 was working properly but suddenly it got very slow and laggy when I tried to debug my code.
I checked all resources on my machine. All seem as before and are available enough.
Even I checked the same IDE with other codes. All runs and debugs fast enough as before.
I also updated my IDE to the last version (currently 16.8.5 by the end of February 2021).
Did anybody has the same experience with the VS2019 ever?
Thanks in advance.
Not sure whether the issue is caused your code with IDE environment together. Please try the following suggestions:
1) disable any third party installed extensions under Extensions-->Manage Extensions-->Installed to check whether an extension caused that.
2) reset settings under Tools-->Import and Export Settings-->Reset all settings and you can also make a backup of the settings
3) close VS, delete all files under C:\Users\xxx\AppData\Local\Microsoft\VisualStudio\16.0_xxx\ComponentModelCache
and also delete .vs hidden folder under your solution folder, bin and obj folder.
4) type devenv /safemode under Developer Command Prompt for VS to start a pure VS and then try your project.
5) create a new project with your same code and check if this works.
Besides, if all do not help, you could try a small reproducible sample with us.
If debugging suddenly becomes slow, you might consider checking your symbol settings and debugging settings. If you for example enable .NET framework source stepping, debugging can be slow, or if you do not cache symbols or disable for example Just My Code or enable other stuff, like IntelliTrace or install a bad extension.
It might not be an alternative for you, but I am pleased to inform you that I have been using Visual Studio 2022 and it is radically faster. Yes, this is not opinionated, this is an observation. It IS faster. Maybe it is because I do not have many extensions on it, but it is also a 64-bit application with less memory pressure on the GC. So you can first check your settings and then give VS 2022 Preview versions for a spin. I have used it for months and the amount of bugs are rather small if you do typically development. For a Preview version, I am impressed with what they are working for nextgen Visual Studio.
You should also clean your solution and delete and bin and obj folders via for example Powershell script to make sure your binaries are updated. Then rebuild.
If you have "live share" extension enabled, perhaps can try to disable / uninstall that. This one was causing my problem.
Ok, #Mr Qian no 3 did the trick for me.
Situation: After a "Cleanup" (Microsoft Visual Studio\Installer\InstallCleanup.exe) my VS2019 was partially gone. Good tool. :-(
After (re)install, I had 2 folders "ComponentModelCache" over 2 folders of 16.0_xxx : 16.0_4f678462 and 16.0_119826cb
I renamed both "ComponentModelCache" folders (you can delete later, when it has effect)
Build ran as never before...
Thank you, Mr Qian
My problems started as I upgraded to Visual Studio 2022 (from 2019) and upgraded to Windows 11 (naughty naughty, two major changes).
Turns out Windows Defender didn't preserve my exceptions. Using this PowerShell script as a template saved a bit of time:
https://gist.github.com/Braytiner/be2497d1a06f5a9d943dc7760693d460
Performance is back to where is was pre my Windows 11/Visual Studio 2022 upgrade.
Visual studio 2019 (16.8.5) has this problem in debugging. I have updated it into 16.11.8 and it works properly.
When I start VisualStudio it frezzes on the start screen. But when I start it a second time while the first instance is open the second instance works fine.
It's not that important but what could cause that problem?
Not sure. Sometimes some Visual Studio extensions are locking up Visual Studio.
I think by default Visual Studio tries to update these extensions
that have been installed automatically.
Recently I was trying to run Visual Studio (at Home) and it would freeze if I tried to open a specific project. But I was busy, so I didn't pursue it further and did other things. Then a week or a few days later I tried to run Visual Studio (at home), and it locked up when I ran it. I tried really hard to fix it.
There is a way I don't like where you can delete all or most of the
extensions from the place Visual Studio installs them, but this is
messy, and it is easy to get rid of something you need, and may hard
to get it back where it works correctly again. So I now recommend against this since there is a better solution now, below!
I searched to find a solution, and someone on a Microsoft board I think said to run from a command prompt as Administrator: DEVENV /RESETSETTINGS, I tried that and it didn't work for me. Then I thought, run DEVENV /? to see what I can see, and I saw :
DEVENV /SAFEMODE
So I tried that and it worked! Note: it was still being run from the Visual Studio Developer Prompt as an Administrator.
Visual Studio loaded up correctly, and I was able to look at the
installed extensions.
Eventually I noticed that they all or a lot of them were disabled (probably because of this SAFEMODE parameter), and I noticed that it the most recently updated were at the top of the list. I noticed that a lot of them had been automatically updated by Visual Studio and started Uninstalling a bunch of the more recent ones, and reverted at least one of them, then later uninstalled it. Eventually, after about 6 to 10 uninstalls, I got it to where Visual Studio would load normally, without the /SAFEMODE parameter! Cool!
So I turned off the automatic updates, so this will never happen automatically again. If I load a new extension or update and existing one manually, I should always exit Visual Studio and reload it after not doing too many updates or installing too many extensions to see if these extensions allow Visual Studio to load.
Sometimes an extension will not freeze Visual Studio, but will have errors. The ones that are the big problem are the ones which prevent Visual Studio from loading all the way and freezing it up. But with the above solution, you can eventually, cleanly, uninstall all the latest updates or new installed extensions until you finally get Visual Studio to load normally!
This workaround should be more widely known, so I am putting my solution to it here. Hopefully what I found should help someone else who is in a hurry, without having a lot of time to burn trying to get Visual Studio running again without freezing!
I use Visual Studio Community 2017, and I got this same issue on startup until I stumbled on this solution that deals with some corruption in the .suo file. Before I open Visual Studio for the day, I first delete the .suo file in my project folder, and it starts up just fine.
It's in a folder called .vs next to the .sln file. You may have to go to folder options View and check "Hidden Items" in order to find this folder. Dig down in that folder and you'll find the .suo file. Delete it. When you startup the project in Visual Studio, it will automatically create a new .suo file. So you'll have to do this every time you reopen.
We have a really big solution with more than 200 projects and thousands of files. Despite of that the solution used to load pretty quickly in Visual Studio 2010 as well as 2012. However, after copying the whole SVN repository to another location, loading and closing the solution suddenly took extreeeemly long. (I am talking about 30-60 minutes here!)
I found a solution myself and I wanted to share it here, hoping that it might save someone quite a few hours of research and staring at the "Preparing solution..." dialog.
When inspecting the devenv.exe process with Process Monitor, I found out that it is pretty busy with accessing the .svn directory. Here is what I did (and this somehow solved the problem):
Kill Visual Studio
Open Visual Studio without loading a solution
Disable AnkhSvn as Source Control plugin (Tools->Options->Source Control->Plug-in Selection->None)
Disable "Document Well 2010 Plus" (VS2010) or "Custom Document Well" (VS2012) in Productivity Power Tools (Tools->Options->Productivity Power Tools) - I read that somewhere and it might have helped as well...
Close Visual Studio
Delete the solution's *.suo file. This is located in the same folder as the solution itself. NOTE: You will lose several settings for your solution, like currently opened files, breakpoints, bookmarks, current solution configuration & platform (e.g. Debug x86) etc.
Restart Visual Studio
Load the solution - it was much faster now!
Close Visual Studio
Open Visual Studio without loading a solution
Re-enable AnkhSvn and the "Document Well"
Restart Visual Studio
Open the solution - it was still loaded in seconds!
I do not know which of these steps actually solved the problem. Probably, not all these steps are required, but I did not want to reproduce the problem to find out which steps may be omitted. :)
None of those helped me, what I did... I watch with ProcMon of sysinternals, filtering for devenv, and I saw a lot of entries of fussionlog. I had enabled fussionlog for debugging purposes some weeks before and didn't think in disabling it. I just had to disable fussionlog and the solution opened faster.
You can open the Visual Studio in the Safe Mode, and then check your plugin and source control settings after opening the project.
Safe Mode means "Starts Visual Studio, loading only the default environment and services."
How :
devenv /SafeMode
Or according to your path
"C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\devenv.exe" /SafeMode
source : https://msdn.microsoft.com/en-us/library/ms241278.aspx
In my case, the following worked without any of the intervening steps suggested:
Kill Visual Studio.
Start Visual Studio directly (i.e., not from the .sln file).
Then, from within Visual Studio, open the solution.
In my case this was all it took to make the problem solution load quite quickly, without the need for me to change any settings or delete any files.
fwiw, I realize this is a late entry, but I found that simply removing (deleting) my large number of breakpoints resolved the excessive load time and compile time.
This action reduced the size of the .suo file from 214MB to 977KB. Let VS handle the .suo file itself.
Compiling and loading now takes < 1 minute instead of 5-10 minutes for a solution with 35 projects. Visual Studio 2012 Pro, update 4.
None of the other answers worked for me. CI compile times were fine, but loading my solution in Visual Studio was taking almost two minutes. VS would then operate just fine until I closed and opened the solution the next time. Different versions of VS all showed the same problem and both safe mode and deleting the suo didn't help.
I ended up following the advice in http://geekswithblogs.net/akraus1/archive/2014/04/30/156156.aspx to use Windows Performance Recorder to instrument VS and find the problem. By looking in Windows Performance Analyzer under the "CPU Usage (Sampled)" section and adding the "Stack (Frame Tags)" column, I was able to dig into the usage of devenv.exe.
Turns out the hot path by count had Microsoft.VisualStudio.Platform.WindowManagement.ni.dll 23 calls down, and below that eventually Microsoft.VisualStudio.ServerExplorer.dll and Microsoft.VisualStudio.Data.Package.dll. That pointed me to look in Server Explorer in the UI and open the Data Connections tab. There I found hundreds of mistakenly added connections that came from the debug web.config's ConnectionString section. Removing those from web.config reduced the load of that individual project from 90+ seconds to almost instant.
I have a different cause for the slow loading of the projects.
My situation is utilizing Git and found that even switching branches was slower than it should be with project load.
Solution: Run Visual Studio as Administrator
Reason: Something with the Corporate laptop is not providing the needed Git tool access (it doesn't recognize that a git repository is in use).
I have not seen any issues with Git or my personal access to any of the project files or Git objects.
I tried the above, but it didn't solve my problem.
Here's how I got around this problem, hopefully it will work for some of you as well:
Open Visual Studio 2013 with no solution.
Create a new C# Console application and save it.
Close Visual Studio.
Reopen the Console solution created in step 2.
Close Visual Studio.
Reopen the solution that was previously hanging on the Preparing Solution dialogue. Mine opened right away, no more hanging.
Using Visual Studio 2015, I ended up creating a new solution, adding the existing projects.
Deleting the *.suo from gehho's answer helped in the past, but didn't help me in this case. There's also another .suo file in a hidden .vs folder at the root of the solution.
There are other answers here for Visual Studio 2015 Visual Studio 2015 is extremely slow
For my case it was due to TFS issue. It thinks that there are more than 5000 pending changes.
The fix is to force TFS to recheck. Go to Team Explorer -> Source Control Explorer and do "Get Latest" on the projects that have pending changes. For things that are already matching TFS, Visual Studio will actually not download anything to your PC. For things that are different with TFS, Visual Studio will let you know and ask you to reconcile the difference.
This is VS 2019 Professional.
In my case there were <import ...> entries in the project files that pointed to
paths no longer available making the loading of the solution hang indefinitely without any form of information give (Shame on Microsoft!).
I encountered this problem only recently (Mar 2021), using VS 2019. It literarily takes 30+ seconds to load the file (each).
It only effects the Layout files. I believe it could be to do with the links within the files. I have not had time to investigate them.
However, I am writing this to suggest that regardless of the cause of the problem, a simple solution is to right click on the file and open it with Notepad to get your work done.
What's the reason for error message "The snapshot is out of date and cannot be used anymore because type tree has been updated, A new snapshow needs to be acquired"?
This error appeared right after I launched VS2010 and added username/pwd to connect to TFS repository.
I am using VS 2010 professional edition.
It happened to me with VS2012 as well after loading the project without source control binding, a local simple WinForms project. All I needed to do was Clean & Rebuild. After that the problem was solved.
This is a bug in Visual Studio. According to http://connect.microsoft.com/VisualStudio/feedback/details/742959/the-snapshot-is-out-of-date "We've taken a closer look at this problem and it isn't one that we'll be able to solve in the next release of Visual Studio."
They recommend waiting around until the background language parser service is done (or, in other words, don't try to be too productive there partner.) My experience is that closing all documents, cleaning the solution, rebuilding it and then closing and re-opening with a pause after does remove the error.
Until you do something silly, like edit code. Then all bets are off again as to when it reoccurs.
I had a similar issue with VS2012 and after rebuilding the solution twice, I still saw the same error message.
Following an advice from a post from this site, I closed the Designer tab, reopened it from the Solution Explorer, and the problem was resolved.
I got this error too, but after I unload project and reload project, the problem was resolved.
Simply restarting Visual Studio 2012 was a workaround for me, but it kept happening about every hour and having to restart visual studio that often was very annoying.
I also found this post which suggests that the Productivity Power Tools are the problem and to simply turn off the Automatic Brace Completion in Tools->Options->Productivity Power Tools. Since making this change I haven't seen the error message again :)
I'll note though that I am using Visual Studio 2012 and the OP is using Visual Studio 2010, but the Productivity Power Tools are available for VS 2010 too, so this may still fix the problem in VS 2010.
The same issue persists in VS2013, but no amount of Clean/Rebuild or restarting VS will help. The only way I can do a successful publish, is to disable the AutoT4MVC extension.
I got this error too. I closed Visual Studio 2012 and opened it again and the error was gone.
I got this error when I had conflicting class names / namespaces. I was referencing a UserControl from a different DLL in my XAML file which had the same name as my XAML file (class name). Maybe this helps.
I used Visual Studio 2012, and just faced this error on my Windows 8. It seems like Turning off the VM and restarting Visual Studio fixed the issue.
I just got this with VS2010.
I had a form with a user control (UCa) with a user control (UCa) from a different project on it. Made a change to the UCb then flicked to the designer for the form and boom! Snapshot error.
Resolved by a full clean and then rebuilding just the UCb project before building the rest of the project.
I'm using Visual Studio 2012, and I got this error when starting Visual Studio, letting TFS connect to the server, and THEN opening my solution. The fix was simply closing VS and launching the solution directly.
I'll throw my two cents in here as well.
I've tried every combination of Clean, Rebuild, Restart, etc. What I've found is that restarting Visual Studio usually makes the problem go away for at least one Publish. Here's the weird part, though. You can also fix the problem by doing absolutely nothing. If you just let Visual Studio sit for about a minute or two, and then publish, it will usually work just fine. There's some background voodoo going on here, and waiting for it to finish seems to do the trick.
I have a solution with two parts that need published. One is a WCF service application, and the other is the ASP.NET MVC5 website itself. Anytime I publish the services, and then try to publish the site I'll see this error. I can publish the services, restart VS, and then publish the site, OR I can publish the services, go get a drink, and then publish the site. As long as I give VS a chance to "settle" between any kind of rebuild and the publishing of the site, everything seems to work as expected.
Take a walk, come back, problem solved. OR if you don't have the time. Clean, Rebuild, Restart, Publish (lather, rinse, repeat).
My visual studio 2010 crashed when some carelessness [bit of madness] mistakenly pressed start button and my Acer timeline got unstable. Two projects where open at the time, one in visual studio 2005 [I have both 2005 and 2010 installed]. Unfortunately I lost all the codes I had done at the time along with those coded even weeks before. Now the project files in both the solutions are those weeks older. Amazingly, the .aspx pages are intact and .cs files are gone.
What can be done to get the lost data? Help please.
Thanks.
Guys TAKE CARE if your Visual Studio crashes, you need to check the backup BEFORE you restart Visual Studio and check if your files are ok! Many people complain that they lost work after a crash, and then they restart Visual Studio, and upon discovering that their code cannot be found in Visual Studio they then check the backup at the location
%USERPROFILE%\Documents\Visual Studio 2010\Backup Files\\
The order is important. Check the backup FIRST, before restarting Visual Studio. If you start Visual Studio and then open your old project it's probable that Visual Studio will overwrite the backup files for that project.
Securing the backup is your FIRST concern. Then start Visual Studio and open your project to see how much damage there is.
You can check:
C:\Users\<username>\Documents\Visual Studio 2010\Backup Files\<ProjectName>\
C:\Users\<username>\Documents\Visual Studio 2005\Backup Files\<ProjectName>\
More information can be found here:
Visual Studio 2010 AutoRecover Feature
I just had the same experience -- losing a source file during a BSOD. Very annoying!
No backup file could be found, and I searched the hard drive for a file containing the class name, but no backup was unturned.
However I was able to get back something resembling my code by decompiling a DLL from the bin/Debug folder using DotPeek. So if you had previously compiled your code successfully, you can get the code (without comments, and with some weird local variable names, etc) via decompilation.
I Had the same problem, I lost code due to BSOD.
the backup folder should store files not saved until they are saved whenever you save the files there are deleted.
I think that maybe they don't remain after a restart as it was empty in my case.
A very good file recovery tool is Recuva. It helped me once, didn't help me second time, though, because I noticed the data loss too late, and all recoverable data got overwritten.
So I used DotPeek, though you'll have to do a lot of work on the disassembled files, they are pretty weird.
Now I put my source tree in Google Drive, because it has file versions and keeps deleted files. Dropbox would do, too.
Git or any other VCS are not solution for this thing, because you cannot have crazy amount of meaningless commits.