We're working with a solution which has multiple projects which references NuGet packages from other solutions.
Every time we do get latest from the TFS server on the solution, Visual Studio (2015) starts reloading each project in the solution which takes a really long time. Now this wasn't always the case, since this started happening only a few weeks back (the solution is a year old).
We have other solutions which were already experiencing this problem and our solution is to close the solution, then do get latest, then reload the project which is much, much faster.
Can anybody explain why this is happening and how to fix this issue?
This has been reported as a bug to MSFT, see Slow project reloading & Reload of projects is slow after call to TFS to get latest changeset. It seems your project files are updated from outside VS, which causes VS to load all them. More details please see the reply from VS IDE team:
Main culprit is, your project files are being updated from outside
VS, which causes VS to load each of them one by one. This is
extremely taxing process and it happens on the main UI thread. Hence,
this ASL logic is on-by-default to alleviate unresponsive solution
loads. Essentially, you’re pointing out a limitation in our ASL logic
that we hadn’t considered. This will be considered for a future
release, thank you.
In the meantime, one way to mitigate the problem would be to force
solution reload by touching the solution file, the *.sln file, which
will trigger ASL to kick in, basically VS thinking you’re doing full
solution load and it will optimize responsiveness time as much as
possible.
Ulzii Luvsanbat
Visual Studio IDE Team
Please try these steps:
Open Visual Studio installer and install the most recent available update for 2017 version.
Open %localappdata%/Microsoft/Team Foundation/7.0/cache and delete all files, then restart Visual Studio and retry.
Related
I don't know when this started, but I discovered that Visual Studio 2013 Update 5 aborts when attempting to open properties for a project within a solution. It seems to only happen when we have more than one project in the solution.
I've been able to reproduce it in two circumstances:
The first project is C++ and the second project is Fortran. Right-clicking on the first project and selecting Properties crashes Visual Studio without a crash dump or any kind of pop-up notification. Visual Studio just ceases to exist. Right-clicking on the Fortran project brings up the property sheet without any problem.
The second circumstance is with two projects, both C++. In this case, I'm able to open properties successfully for the first project, but not for the second one.
In every case I've tried where there's a one-to-one solution and project, it's working fine. A colleague who's working with VS 2013 Update 4 verified that the crash occurs for him as well.
We don't know when this started, but historically, we've opened these property sheets many, many times. However, it's probably been a few months since I've worked on a mixed-language process, and same with my colleague.
I've turned on logging and there was a complaint in the log about two versions of the Desktop SDK having the same internal ID. I removed one of those altogether, but that didn't seem to affect anything. It's also not clear if that error has any relationship to the crash.
I've also done a repair on Visual Studio, and that did not correct the problem.
I've also tried deleting the .suo and .user files. Again, no luck.
I've done quite a bit of googling but haven't found anything that matches this specific problem.
Any ideas?
Thank you,
Doug
I'm currently evaluating Visual Studio 2015 RC. I've noticed when running the IDE, The Visual Studio 2015 process is constantly at around 25% CPU usage. Even without a project loaded and without the welcome page it is gobbling up 25% CPU usage at a constant rate. No other applications running other than background services. All other running processes use around an additional 2 to 4 percent CPU overall.
This behavior has also been noticed in Visual Studio 2013.
Is anyone else seeing this behavior? Is this normal? Any suggestions?
Had this same problem. Processor constantly at 45-50% even when the IDE is completely idle.
Turns out the problem is the Microsoft Git Source Code provider.
I turned that off and processor dropped to 0 and the IDE became much more usable.
In my case disabling Telerik ASP.NET MVC Extension solved high CPU issue.
High CPU load started on solution load and didn't drop (40% with one, 80% with two solutions) until VS was closed or even sometimes after (had to kill the process).
Tools->Extensions and Updates->Installed, find the extension and click 'Disable'.
In my case all reference counts tried to update every time when I edit code.
I have just turned them off. You can do it this way.
It’s not to be expected that Visual Studio should chew up continuous CPU time.
I am running Visual Studio 2015 Community RTM right now with a medium sized project open, and am not seeing any ongoing CPU usage (according to Process Hacker 2, which shows usage as small as 0.01 percent). It’s just blank, which means not even 0.01% CPU usage is registering.
Keep in mind that IntelliSense scans your project files in the background to build the database for popping up its suggestions, etc.
Choosing Project > Rescan Solution from the menus will result in that process being done over, which will cause the CPU to be used for a time. But it should ultimately go quiet.
Seemingly forever, there have been times when deleting the Intellisense Database files and doing a full rescan solves “odd behavior” type problems. I don’t know if it’s the “prescribed” method, but if I suspect an IntelliSense problem I just delete the .sdf file in the project folder if I want to make sure Visual Studio starts with a clean slate. This isn’t necessary very often.
I also had this problem, constant 20-40% CPU when idling (Visual Studio 2015 update 1). I noticed that other local repositories of the same code did not have this problem.
I deleted the problematic local repository and took a new checkout, this solved the issue for me. Why this worked, I unfortunately cannot explain...
I run resharper, turned that off and turned off the Microsoft Git provider and still had high CPU issues, devenv.exe would also run after close... until recently.
It appears VS 2015 Update 2 has resolved these issues!
https://www.visualstudio.com/en-us/news/vs2015-update2-vs.aspx
In my case; "Visual Studio 2015 Update 1" gone crazy editing JS files regarless of the length of the source. It used high CPU and the editor is even freezed. I fixed the issue by disabling the 3rd party add-ons by one-by-to detect the buggy one causing VS 2015 malfunctioning.
Hope it works.
In my case, the culprit was Node.js tools for Visual Studio. I had v1.1.2 installed and the cpu was constantly around 25-40%.
A switch to Node.js Tools v1.2 RC resolved the problem completely after an initial high load that went away in a couple of minutes.
In my case it was either the Roaming Extention Manager or most probably the azure worker role project in my solution. If you have one of these try unloading it and restart visual studio. I can reproduce it but I don't know why it happens.
I've noticed also that when running and stopping a debug episode on the local server, if the page is still open in the browser, VS will continue to run at high CPU. Closing the browser page stops this.
I want to share my experience,
In my case I had to diable all extensions and updates and code analysis c#.
1-For extensions and updates :
Tools => Extensions and updates
2-For the code analysis
Solution explorer => right click on the project => Properties =>Click on the tab "Code analysis" => click on the "Open" bouton => Uncheck the checkbox "Microsoft.CodeAnalysis.CSharp" => save and exit.
Cpu usage descended to 1 %.
In my case, The .suo file in Visual Studio was the culprit. Deleting it fixed my issue.
Refer below link for more details.
https://shemeerns.com/2014/04/04/the-solution-user-options-suo-file-in-visual-studio/
I have a solution that is composed of six assemblies. When I initially load the solution and try to build it, it seems that Visual studio just hangs. It says that it’s building, but I see no updates in the Output window. The CPU jump to 100% usage. The only thing I can do is to Cancel the build or to shut down VS 2012 through Task Manager (which takes forever since I have little use of the system at the time due to the 100% cpu usage).
The only way I have been able to build my solution is to rebuild it. Basically, I delete the .sln file. I then create a new one (by opening the first assembly) and build it. I open the next one…build it. I repeat this process until I have all assemblies built. Only after this am I able to rebuild the solution.
Note, that at some point, not sure when, I will once again not be able to build the solution and I have to go through this process over again.
Any ideas as to what might be causing this?
Here is some more information.
I am running VS 2010, VS 2012 and VS 2013 under a VMWare Virtual Machine. I do not think this matters as it open happens (as far as I can tell) with this one solution. It doesn't matter which version of VS I open it with, it will hang.
Really hoping someone can help me resolve this as it is eating into productivity.
UPDATE-----------------------
It appears that I am able to build this solution on the command line using MSBUILD. However, I still cannot debug the application since VS just hangs.
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).