I experience that on several different machines, with plugins, without plugins, with VB.net or c# solutions of many different sizes, closing the solution in VS 2005 generally takes significantly more time than actually building the solution.
This has always been the case for me since I started using Visual Studio 2005, so I have learned to live with it, but I am curious:
What on earth is visual studio doing when you have actually told it to shut down? Is it significant? Is it configurable, can you turn it off?
What on earth is visual studio doing
when you have actually told it to shut
down?
You can use Process Monitor from sysinternals. It maybe because of some plugins. Try resetting your Visual Studio settings (Tools->Import and Export Settings->Reset All Settings).
I've found that closing all the open documents before you close the solution helps speed it up. Or maybe it's just a perception thing, but it seems faster :)
Related
Since upgrading visual studio 2015 and using ssis, we have experienced that the editor for Script Task/Component takes around 30 seconds to open.
i have seen some older posts suggesting to add "127.0.0.1 crl.microsoft.com" to the local hosts file. But has not impact on the issue i'm experiencing.
Really hope someone out there has had the same issue and maybe found a solution?
Try to clean up your temp folder, could help if you use it for temp files in your etl
C:\Users\UserName\AppData\Local\Temp
One more thing - did you get an new antivirus lately or changed policies ? Once I had this problem and Sophos really killed any performance of my visual studio. We set it to reads only and performance went up.
I have VS 2015 Community using C#. I created a WPF application.
When I hit F5 or play Visual Studio starts to debug the application as normal. I even see the Diagnostics showing Memory Usage and CPU (but it locks up, for example at 20 ms and stays there). The problem is that sometimes the application will open and run when debugging, most the time it does not. Important to note that visual studio itself isn't locking up, just the diagnostic tool window.
If I run without debugging the application opens as normal and there are no problems, but if I want debugging the application doesn't even open.
I am sorry I have no errors to show because I get no errors or warnings. It simply just wont open during debugging.
Is there a patch/update I missed or has anyone had this problem before?
I had what sounds like the same problem. I disabled Enable Diagnostic Tools while debugging in Tools → Options → Debugging. In my case it was some kind of conflict with Symantec (per the event log). Not ideal but being able to debug is better than having diagnostics.
UPDATE
I looked up the help desk ticket I filed for this incident and it was not the event log, I remembered that incorrectly. What was happening was that the edpa.exe process (a Symantec process which is controlled by group policy at my office) was thrashing the processor whenever I would debug. The fix/workaround is the same. I have since got a new PC and I do not experience the problem.
Have you tried restarting Visual Studio / PC or re-building the solution?
It may help.
There should be no conflict with Symantec NIS (current version 22.6.0.142). It (your question submittal plus the accepted answer) sounds more like an available memory issue; my NIS reports high memory usage when I start up VS, so I sometimes (not always) have Diagnostics failing to start up, but debugging always would continue. Perhaps adding more physical memory is the solution for you; but for now, turning off Enable Diagnostic Tools While Debugging is just a bandaid.
With Visual Studio 2015 I have noticed that if I have multiple solutions open with a common project to all solutions, if I so much as edit and save one .cs file belonging to the common project, all Visual Studio 2015 instances will consume CPU for 10-15 seconds. Note that the common project is fairly large.
I don't recall this happening with Visual Studio 2013. It is common in my workflow to have 8-9 instances of Visual Studio open all with solutions referencing the common project, so I feel as though I would have noticed this behavior with Visual Studio 2013 (my development machine has 32 GB of RAM which makes this type of workflow possible).
I have tried:
Disabling CodeLens
Uninstalling ReSharper
Disabling the four C# Intellisense features found in Tools->Options
Temporarily Disabling Static Code Analysis Solution Wide (for all loaded solutions)
I also launched a separate instance of Visual Studio 2015, enabled Microsoft Symbol Servers and profiled (via Debug-> Profiler-> Performance Explorer -> Attach/Detach) an offending Visual Studio instance while it was consuming High CPU.
This image shows the profiler summary and you can see from the graph high CPU usage between ~12s and ~27s.
84.46% of the samples were in Thread::intermediateThreadProc, and the majority were exclusive samples, but of the inclusive samples, it appears as though it was doing some sort of code analysis.
With this information I assume that some sort of background code analysis is being performed with all Visual Studio 2015 instances (including those in the background). Does anyone know how to disable this? Or if my assumption is incorrect, any other suggestions?
Update 9/12/2015
Interestingly, if I perform the same profiling with ReSharper 9.2 installed, I get a similar result, but with JetBrains.Platform.Satellite.exe at the root of the "Hot Path" (instead of devenv.exe).
Update 10/11/2015
I believe this is the issue:
How to disable real time compilation in Visual Studio 2015
Is there a way to disable real time compilation on save? Or at least have it not be so intrusive? The operation most likely to follow "Save" is "Build", and because all of the visual studio instances are recompiling their respective solutions (without being asked), the "Build" operation in the active solution is severely hindered.
Found here (http://www.itgo.me/a/x8021838007883560399/how-to-disable-real-time-compilation-in-visual-studio-2015) :
"go to tools, options, text editor, C#, Advanced and uncheck Enable full solution analysis. This should stop your problem as the solution won't be checked every time unless you build it."
When starting Visual Studio 2013 Pro (Update 4 installed) I very often get this error message (several times a day now) for the past about two weeks:
The 'Microsoft.VisualStudio.Editor.Implementation.EditorPackage' package did not load correctly.
I know I can correct this problem by closing Visual Studio and deleting:
%LocalAppData%\Microsoft\VisualStudio\12.0\ComponentModelCache
I have never seen it before that time and as far as I found out in the Internet it was possibly introduced with Update 3.
Well, the problem is that it is annoying to restart Visual Studio several times a day, and I was wondering if anyone else is experiencing this and knows how to solve it for good or what the cause is.
I noticed that it happens extremely often if I work in more than one instance of Visual Studio in parallel. This one is a killer. But still I suspect a third-party component to be involved or it is the size of one of the solutions (about 70 projects). I tried to deactivate some extensions I newly installed and need for the big project, but to no avail.
Just as information: I am working with C#. When working in parallel with projects open in several instances of Visual Studio I never had problems before.
Does anyone have the same problem to this extend or possibly have a better solution than deleting the folder and restarting?
This has become a popular question so I thought I add an explicit answer how to (at least) temporarily fix the problem as already stated in the question:
I stop Visual Studio and delete the following folder (completely, not just contents)
%LocalAppData%\Microsoft\VisualStudio\12.0\ComponentModelCache
If you are using VS2015, then the path should be:
%LocalAppData%\Microsoft\VisualStudio\14.0\ComponentModelCache
If you are using VS2017, then the path should be:
%LocalAppData%\Microsoft\VisualStudio\15.0\ComponentModelCache
I don't keep a backup of the folder. It is created automatically again when starting Visual Studio.
I have never found a solution how to permanently fix the problem in that working environment. In my new developing environment (new projects and new workplace) the problem never happens.
This is what helped me... seemed to happen after Windows Server 2012 SP install...
https://connect.microsoft.com/VisualStudio/feedback/details/1123745/setsite-failed-for-package-microsoft-visualstudio-editor-implementation-editorpackage
devenv /clearcache
devenv /updateconfiguration
In that case you can start Visual Studio setup again and choose the option showing two options, Repair and Uninstall. Then click Repair and when repair is done, restart the computer. Then the issue has been resolved.
I am encountering a big performance problem when building lately, and I suspect that it's some sort of add-on problem.
Disabling all my extensions did not help. However, running vs in safemode (devenv /safemode) helped a great deal.
Now I just need to figure out what was different between VS running in safe mode vs. running normally. Is there a better way to diagnose this performance problem?
I did a quick google search and came up with the following:
"There’s a built-in command line switch devenv.exe /log to log Visual Studio activity, e.g. which packages got loaded, etc. "
Also, most versions of Visual Studio accept a /SafeMode option to start without all the extensions/plugins