I am experiencing this weird problem with Visual Studio 2022.
I created the skeleton of a new web application using individual accounts.
I have run the first migration, created some default accounts in the aspnet identity tables and
finally launched the application to test if everything was correctly setup in my PC.
Visual Studio compiles the application without problems and launch the defaul browser (Edge).
The standard Welcome page appears but immediately Visual Studio pops to the front doing nothing.
No errors, no messages nothing wrong. Just the code window here to obscure the browser window.
Now, I switch to the browser window and click on the Login link.
Again, the login window briefly appears in the browser but it is immediately obscured by Visual Studio.
Switch again to the browser, compile the required fields and click on login.
Again Visual Studio thinks that he is the best app on the planet and brings itself on the foregroud.
I have tried to switch to another browser, but the results are the same.
I have tried with an existing application written with Visual Studio 2019, but again the "pop in front of everything" still happens.
I have tried to search for this problem but probably I haven't find the right keywords to represent this problem correctly to a search engine.
I think that probably I have something wrong in the Visual Studio configuration, but it is practically impossible to find something there if you don't know what to look for.
The only option that seems to be related is "Bring Visual Studio to the foreqround when breaking in the debugger" but even after uncheking the option the "pop to front" persists.
So my question is simple. Has anyone experienced a similar behavior? If yes how have you fixed it?
Well, probably this situation is so messed that none will ever see this post.
Nevertheless I would like to share how I have finally resolved the question and leave here a warning for future readers.
The cause of Visual Studio 2022 hiccups is, probably, the import of Visual Studio 2019 settings.
I thought that it was a good idea to set 2022 with the same options used in the last 3 years so, after installing VS 2022
I used this very useful menu (Tools->Import Export Settings) to export all the Visual Studio 2019 Settings in an XML file and I reimported it in 2022.
I thought, if the file is not compatible with VS2022 surely it will abort the import. Right?
No, Visual Studio 2022 doesn't complain during the import of 2019 settings.
But something in that exported file should be very broken.
I have resolved the problem with these steps
Close Visual Studio 2022
Open a command prompt window with administrator rights
Change to the install folder for Visual Studio 2022 and then change dir to subfolder "Common7\IDE"
Finally execute the command
devenv /ResetSettings
After this everything started to work as expected without problems.
I have saved the broken VS2019 setting file and tried to compare it with one produced after the reset,
but they have too many differences to extract something useful to identify the specific problem area
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.
I'm running Visual Studio 2013 Pro (RTM version) on my formatted PC (Windows 8.1 fresh install).
I don't know why, but Visual Studio 2013 Pro is very very slow! Slow for building, debugging, navigating in the IDE... my hard disk drive LED is not lighting up at all!
I'm on a little MFC (C++) project using the Boost library.
Any ideas?
It is something concerned with the graphics drivers. If you update them you will be fine.
Or you can disable the hardware graphics acceleration in Visual Studio according to these steps:
In Visual Studio, click "Tools", and then click "Options".
In the Options dialog box, navigate to the "Environment > General" section and clear the "Automatically adjust visual experience based on client performance" check box. (Refer to the following screen shot for this step.)
Clear the "Use hardware graphics acceleration if available" check box to prevent the use of hardware graphics acceleration.
Select or clear the "Enable rich client visual experience" check box to make sure that rich visuals are always on or off, respectively. When this check box is selected, rich visuals are used independent of the computer environment. For example, rich visuals are used when you run Visual Studio locally on a rich client and over remote desktop.
References:
You experience performance issues, product crashes, or rendering issues in Visual Studio 2013
Try to set Current source control plug-in to None (menu Tools → Options → Source Control), if you are using the Microsoft Git provider, which seems to slow Visual Studio 2013 down more and more the larger the repository gets.
I had the whole Dojo Toolkit framework under source control using the Microsoft Git provider, and it got to the point where there were delays from the time I hit a key to the time the glyph would appear on the screen. That bad.
When/if you need Git again, you can switch to the TortoiseGit provider or Git-Extensions, both will work without slowdown. I like Git-Extensions, personally.
I too have struggled a bit with bad performance in Visual Studio 2013 (Premium). Pretty much the same issues as TS had. Slow navigation, scrolling, building... just about everything. Luckily I have manage to solve my own problem by disabling Synchronized Settings in Visual Studio.
Go to menu Tools → Options → Environment-Synchronized Settings and remove this option by unchecking the checkbox.
In the case of web applications, another cause of slow building and debugging (but not IDE navigation) could be the Browser Link feature.
I found that with this switched on, building would take 4 times longer and debugging was painful - after every postback, web pages would freeze for a few seconds before you could interact with them.
I was using a solution upgraded from Visual Studio 2012. Visual Studio 2013 also upgraded the .suo file. Deleting the solution's .suo file (it's next to the .sln file), closing and re-opening Visual Studio fixed the problem for me. My .suo file went from 91KB to 27KB.
I had the same problem and the only solution that worked for me was to follow the three steps presented below:
Clean the WebSiteCache folder (you may find it at
C:\Users\%USERNAME%\AppData\Local\Microsoft\WebSiteCache)
Clean the "Temporary ASP.NET Files" folder (find it at
C:\Users\%USERNAME%\AppData\Local\Temp\Temporary ASP.NET Files)
Restart Visual Studio
What fixed it for me was disabling Git by setting Current source control plug-in to None in Visual Studio, menu Options → Source Control:
This issue seems to be because of uninstalling the SQL Server Compact edition (4.0).
I was having this issue, and it got fixed after installing the SQL Server Compact edition 4.0.
On closing Visual Studio 2013, I was getting a message to install SQL Server Compact edition as a C++ project needed some thing... can't put finger on anything.
Resolve this issue by installing Microsoft SQL Server Compact 4.0
Microsoft SQL Server Compact 4.0
I can advise an option like this.
CodeLens can be disabled like as at the picture. It gives a lot of performance goodness.
If you are debugging an ASP.NET website using Internet Explorer 10 (and later), make sure to turn off your Internet Explorer 'LastPass' password manager plugin. LastPass will bring your debugging sessions to a crawl and significantly reduce your capacity for patience!
I submitted a support ticket to Lastpass about this and they acknowledged the issue without any intention to fix it, merely saying: "LastPass is not compatible with Visual Studio 2013".
I had the same problem and all the solutions mentioned here didn't work out for me.
After uninstalling the "Productivity Power Tools 2013" extension, the performance was back to normal.
One more thing to check; for me it was Fusion logging.
I'd turned this on a very long time ago and more or less forgotten about it. Getting rid of the 5000+ directories and 1 GB of logged files worked wonders.
There is a good workaround for this solution if you are experiencing slowness in rendering the .cs files and .cshtml files.
Just close all the files opened so that the cache gets cleared and open the required files again.
Visual Studio Community Edition was slow switching between files or opening new files. Everything else (for example, menu items) was otherwise normal.
I tried all the suggestions in the previous answers first and none worked. I then noticed it was occurring only on an ASP.NET MVC 4 Web Application, so I added a new ASP.NET MVC 4 Web Application, and this was fast.
After much trial and error, I discovered the difference was packages.config - If I put the Microsoft references at the top of the file this made everything snappy again.
Move the Microsoft* entries to the top.
It appears you don’t need to move them all - moving say <package id="Microsoft.Web.Infrastructure" has an noticeable effect on my machine.
As an aside
Removing all contents of the file makes it another notch faster too*
Excluding packages.config from Visual Studio does not fix the issue
A friend using Visual Studio 2013 Premium noticed no difference in either of these cases (both were fast)
UPDATE
It appears missing or incomplete NuGet packages locally are the cause. I opened the Package manager and got a warning 'Some NuGet packages are missing from this solution' and choose to Restore them and this sped things up. However I don’t like this as in my repository I only add the actual items required for compilation as I don’t want to bloat my repository, so in the end I just removed the packages.config.
This solution may not suit your needs as I prefer to use NuGet to fetch the packages, not handle updates to packages, so this will break this if you use it for that purpose.
For me, the problem was the Start page -- it was downloading content and causing Visual Studio to hang.
The only solution for me was to:
Kill the DevEnv process from Task Manager
Start Visual Studio in Safe Mode from the command line:devenv.exe /safemode
Go to menu Tools → Options, and select the Environment/Startup options
Choose "Show empty environment" for the startup action
Close Visual Studio
Restart normally
Running unit tests was slow. It was a ReSharper issue.
Menu ReSharper → Options → Environment → General ... Clear Caches
Menu Tools → Options → ReSharper → General ... Suspend Now
Close Visual Studio
Delete the .suo file.
Open Visual Studio again.
Re-enable ReSharper.
I also had an issue with a slow IDE.
In my case I installed
ReSharper
Npgsql (low chance to cause the problem)
Entity Framework Power Tools Beta 4
The following helped me a bit:
Disabled synchronization - menu Tools → Options → Environment-Synchronized Settings
Disabled plug-in selection - menu Tools → Studio → Options → Source Control.
Disabled Entity Framework Power Tools Beta 4 - menu Tools → Extensions and Updates
Uninstalled JetBrain's Resharper - WOW!! I am fast again!!
Change the Fusion Log Value to 0. It solved my issue.
This is the FusionLog key in the registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion
Check ForceLog value (1 enabled, 0 disabled).
I was also facing this issue for quite long time. Below are the steps that I perform, and it works for me always:
Deleting the solution's .suo file.
Deleting the Temporary ASP.NET Files (You can find it at find it at %WINDOW%\Microsoft.NET\Framework\Temporary ASP.NET Files)
Deleting all breakpoints in the application.
Visual Studio 2013 has a package server running, and it was spending up to 2 million K of memory.
I put it to low priority and affinity with only one CPU, and Visual Studio ran much more smoothly.
Performance Explorer
Have you been using menu Analyze → Performance and Diagnostics? I have! It's awesome! But you may want to clean up.
Open the Performance Explorer. If you collapse all of the items in there, select all, then you can right click and do Delete.
My solution opens faster and is in general running much faster now.
Also you may notice changes to your sln file as shown. For me, this section was deleted from the sln.
GlobalSection(Performance) = preSolution
HasPerformanceSessions = true
EndGlobalSection
In Visual Studio 2015 Community edition, I've experienced a very (very) slow IDE after changing the "Environment Font" on menu Tools → Options... → Fonts and Colors.
Reverting this options back to the default value ("automatic") solved it immediately.
I had similar problems when moving from Visual Studio 2012 → Visual Studio 2013. The IDE would lock up after almost every click or save, and building would take several times longer. None of the solutions listed here helped.
What finally did help was moving my projects to a local drive. Visual Studio 2012 had no problems storing my projects on a network share, but Visual Studio 2013 for some reason couldn't handle it.
I had a Visual Studio 2013 installed, and it was running smoothly. At some point it started to get sluggish and decided to install Visual Studio 2015. After install, nothing changed and both versions were building the solution very slow (around 10 minutes for 18 projects in solution).
Then I have started thinking of recently installed extensions - the most recent installed was PHP tools for Visual Studio (had it on Visual Studio 2013 only). I am not sure how can an extension affect other versions of Visual Studio, but uninstalling it helped me to solve the problem.
I hope this will help others to realize that it is not always Visual Studio's fault.
I added "devenv.exe" as an exclusion to Windows Defender. This solved my problem completely. People can try this as their first try.
I have the same problem, but it just gets slow when trying to stop debugging in Visual Studio 2013, and I try this:
Close Visual Studio, then
Find the work project folder
Delete .suo file
Delete /obj folder
Open Visual Studio
Rebuild
None of the suggestions worked for me, but I did solve my problem. I had tried most of the other recommendations before coming to the following solution.
My Scenario/Problem:
Using Visual Studio 2017 with ReSharper Ultimate. Keyboard input in the IDE got super slow as others have described. The last change I made to my solution was to add a new web site project, so I looked into that. After trying a lot of things, I tried adding a second web site project, so I could try to replace the first one, and Visual Studio just tanked after that. It wouldn't even load the solution anymore.
My Solution:
I forced Visual Studio closed and then I removed the newly added web site project(s) from the .sln file using Notepad. After saving and starting Visual Studio, my solution loaded quickly and everything seemed to be back to normal. I added a new Web Site with a slightly different configuration (see the thinking below), and the problem did not present itself again.
My Thinking:
I think the problem stemmed from creating the new web site project and using a file system path to a network share that is hosted in Azure. I'm working over VPN which tends to slow things down, and I occasionally experience various routing problems with some services, so my problem/solution might be a bit of a snowflake. I changed the file system path to be a local repository and will publish the files as needed which seems like a much better way to go.
I had a Visual Studio behavior where the typing was slow for my HTML files. Previously when I installed, I guessed that because my HTML files were generic HTML that the need to install any web development tools from the workload component of the installer was unnecessary. I went back and installed this bit and Visual Studio behavior became as I expected it.
This already has a bunch of answers here, but a general way to easily boost Visual Studio is to clear your temp files.
Press the Windows Key and R, and enter 'temp'. Press enter, and provide any administrator permission if you need to. Then press Control A to select all, and hit the Del key. Remember to provide any administrator permissions, and if 'the item is already in use' then just press skip.
After this, Press Windows Key and R again, but this time type '%temp%'. Repeat the previous steps in the new directory.
Finally, empty the recycle bin.
This might not help a ton, but it should boost general performance.
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.