I'm working with an ASP.NET MVC project that seems to be having some issues when attaching to the IIS process (w3wp.exe). I'm running the solution and IIS 8.5 on my own local machine so I wouldn't think that this has anything to do with our network. What's strange to me is that I'm able to hit the breakpoints on any other solution I debug locally.
The issue I'm having exactly is that the breakpoints turn to red, hollow circles and never get hit. Usually the fix for this is a Clean/Rebuild of the solution but this hasn't worked. I've confirmed the code is being updated by adding "throw new Exception" to a page and ensuring it shows the exception. Again, this problem is only happening with this one solution. Any other solution I run the debugger with works fine. I've also tried restarting the app pool, the website, IIS, and also my computer.
A few of the articles I read mentioned that anti-virus programs can block a remote debugger from accessing the process. However, the entire setup is contained on my local machine so it doesn't sound like that would be the issue. It does concern me a bit though because we recently hired a new IT guy that's been making a lot of changes to everyone's machine.
One other point to add that's unique about this web application is the binding in IIS. The binding is "*" in order to leverage some custom functionality related to subdomains.
In the meantime, I'll continue to look for a solution but if anybody has any ideas what may be causing this one solution to not debug properly I'd really appreciate it.
EDIT: Found a solution that suggested deleting the ASP.NET temporary files. No luck.
Solved. Ended up being an incorrect configuration selected in the debug menu. I had mistakenly switched it to a release configuration that could not load the symbols for the document. Switched it to a debug configuration and the breakpoints hit just fine now.
To add on to what Abacus mentioned below, it could also be a web.config transform that is messing with your build. In our case, we have Release configurations that remove the debug attribute from the web.config's compilation section. Below is a screenshot of an example and Visual Studio's dropdown list of build configurations.
NOTE: Also make sure your Platform is correct along with the configuration. In my case, Dev.Debug|Mixed Platforms does not correctly build the solution but Dev.Debug|Any CPU will.
I struggled forever trying to fix this. Finally this is what did it for me.
Select Debug->Options->Debugging->General
Tick Enable .NET Framework source stepping.
(This may be all you need to do but if you are like me, you also have to do the ones stated below. The below solution will also fix errors where your project is loading old assemblies/.pdb files despite rebuilding and cleaning.)
Select Tools -> Options -> Projects and Solutions -> Build and Run,
Untick the checkbox of "Only Build startup projects and dependencies on Run",
Select Always Build from the "On Run, when project are out of date" dropdown.
Enable 'Managed Compatibility Mode'. Go to Tools->Options->Debugging and enable Managed Compatibility Mode.
In my case this solution is useful:
Solution: Disable the "Just My Code" option in the Debugging/General settings.
Reference: c-sharpcorner
I know this is not the OPs issue, but I had this happen on a project. The solution had multiple MVC projects and the wrong project was set as startup.
I had also set the configuration of the project(s) to just start process/debugger and not open a new browser window.
So on the surface it looks as if the debugger is starting up, but it does so for the wrong process. So check that and keep in mind that you can attach to multiple processes also.
Silly mistake that left me scratching my head for about 30 minutes.
The issue was resolved by unchecking the
Properties > Build > Optimize Code
setting on the web page properties screen (under General).
Right click on your project, then left click Properties, and select the Web tab.
Verify whether the correct server is selected for your case:
IIS Local
IIS Express
Go to Visual Studio Menu:
Debug -> Attach to Process
And then click the Select button, as in the image below:
Then make sure the "Automatically determine the type of code to debug" option is selected, like this:
One of my projects in my solution was set to Release mode. I changed it back to Debug mode, and the breakpoints are hitting now.
I had the same issue in a Xamarin.Forms project. The fix was manually converting the PCL from .NET 4.6 to .NET Standard 2.0.
For Visual Studio Mac: make sure you do it for each project
In Visual Studio 2017 you need to make sure you're not in release configuration mode.
Open the build menu ddl
Click configuration manager
Change from 'release' to 'debug'
In my scenario, I've got an MVC app and WebAPI in one solution, and I'm using local IIS (not express).
I also set up the sites in IIS as real domains, and edited my host file so that I can type in the real domain and everything works.
I also noticed 2 things:
The MVC code debugging was working perfectly.
Attaching to process worked perfectly too. Just when I was debugging it didn't hit the breakpoint in my API.
This was the solution for me:
Right click webapi project > properties > Web > Project URL
By default it points to localhost, but since I set up the site in IIS, I forgot to change the URL to the website domain (i.e. instead of locahost, it should say http://{domain-name}/).
If anyone is using Visual Studio 2017 and IIS and is trying to debug a web site project, the following worked for me:
Attach the web site project to IIS.
Add it to the solution with File -> Add -> Existing Web Site... and select the project from the inetpub/wwwroot directory.
Right-click on the web site project in the solution explorer and select Property Pages -> Start Options
Click on Specific Page and select the startup page (For service use Service.svc, for web site use Default.aspx or the custom name for the page you selected).
Click on Use custom server and write
http(s)://localhost/(web site name as appears in IIS)
for example: http://localhost/MyWebSite
That's it! Don't forget to make sure the web site is running on the IIS and that the web site you wish to debug is selected as the startup project (Right-click -> Set as StartUp Project).
Original post: How to Debug Your ASP.NET Projects Running Under IIS
In my case I had a string of length 70kb. Compiler did not thrown any error. But Debugger failed to hit the break point. After spending 3 hours and scratching my hair I found the cause for not hitting the break point. After removing 70kb data break point worked as normal.
If none of the above work, double-check your code. Sometimes the reason why the breakpoint appears to not be hitting is due to the block of code containing the breakpoint is not being executed for sometimes inadvertant reasons.
For example, forgetting the "Handles Me.Load" has gotten me a few times when copying and pasting code:
Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs)
--this block of code will not execute
End Sub
vs
Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
--this block executes
End Sub
You can't hit breakpoints while attached to IIS process if you haven't logged into your Microsoft account in VS2017.
In my case the actual process was different from the original started process.
Usually we bind the local-hosted services through the w3wp.exe process. In my case a custom process was used. Changing to that solved the problem.
One more thing, change from Release to Debug mode. In release mode PDB files are not getting updated with breakpoints details. So make sure you are debugging your application in Debug mode.
Right click on your project, then left click Properties, and select the Web tab.
Debuggers > ASP.NET
My case is not mentioned here:
I have to run the web project on a fake domain (settup on IIS and /hosts/etc) because of the callbacks from a third party site.
I was seeing two w3wp processes in the process list of VS:
w3wp.exe User Name: IIS APPPOOL\Default app pool
w3wp.exe User Name: IIS APPPOOL.svc
I had to to manually attach to second one to be able to debug.
So I realised the app pool of my Fake domain in iis is not set to "Default app pool"
https://manage.accuwebhosting.com/knowledgebase/2532/How-to-change-application-pool-from-IIS.html
As soon as I changed the domain's app pool to the "Default app pool" visual studio started to debug the web app.
If any of your components are Strong Named (signed), then all need to be. If you, as I did, add a project and reference it from a Strong Named project/component, neglecting to sign your new component, debugging will be as if your new component is an external one and you will not be able to step into it. So make sure all your components are signed, or none.
It might also be (which was the case for my colleague) that you have disabled automatic loading of symbols for whichever reason.
If so, reenable it by opening Tools -> Options -> Debugging -> Symbols and move the radiobutton to "Load all modules, unless excluded"
In my case with 20+ projects in one solution, I included the project (I would like to debug) in the solution startup
Right-click solution-->Startup Project->Multiple startup projects->For project you want to debug select "Start" in action.
Now you should be able to hit those break points, especially projects which may be helper classes.
in some cases the cases the problem is in IIS. if your debug worked and suddenly stopped working , use IISReset to reset the IIS thread-pools.
I hate to admit missing something so simple, but hopefully this will help someone else. In my case, I am using local IIS and the website is running on an application pool, so when you attach the debugger to a process, be sure to checkmark "Show processes from all users" so that you can select the appropriate process.
In my case , changing Solution Platform from x86 to Any Cpu solved the problem.
I just ran into this problem. What worked for me was to change Active Solution Platform to x86 instead of AnyCPU;
Click Build
Click Configuration Manager
Select x86 from the Active Solution Platform Combobox.
Just another reason why breakpoint might not get hit: I replaced the reference to the DLL by a reference to the project. Upon build, no PDB file got created and so no breakpoint got hit. The Problem was that I forgot to do the same with the other projects in the solution. After replacing the references (DLL >> project) in all projects, the PDB got created and breakpoints worked like expected.
click on Debug.
Select [Debugging].
Select the [General].
Disable the "Just My Code"
Click [OK] and rebuild the project.
To delete project's bin and objects folders may be helpfull
Another reason a breakpoint might not be hit is that you are not debugging the site that you think you're debugging, due to anomalies in your site links. Case in point: Assume, when starting the debugger, that it normally launches a localhost page (as shown in the browser address bar). If reaching the breakpoint code entails first clicking a link on that localhost page to go to a different page, you must ensure the browser is still pointing to localhost after the click. If it's not, then your breakpoint will never be hit and you have to fix your links first. Kind of an obvious problem, but easy to overlook.
I'm at wit's end. Visual Studio is typically painfully slow to debug or just plain load ("start without debugging") my ASP.NET MVC sites. Not always: at first, the projects will load nice and fast, but once they load slow, they'll always load slowly after that. I could be waiting 1-2 minutes or more.
My setup:
I'm using Visual Studio 2012 Express, currently, but I've had the same problem in Visual Studio 2010 Express as well. My solution is stored on a network drive; specifically, it's My Documents redirected to a network drive, if it matters. (It shouldn't. There are times where my site loads very fast under this setup.)
I load in Internet Explorer 9 usually, but the same problem happens in Firefox.
This can happen in any ASP.NET MVC project I work on, and it seems to revolve around having DisplayTemplates, which all my ASP.NET MVC projects do. And it's all C# and Razor if that mattered.
Symptoms:
The system will load my symbols hundreds of times. Basically, the following, but there are at least 300 such rows, each with ever-so-slightly different DLL files for the same CSHTMLs:
'iisexpress.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\b63f8236\6775085d\App_Web_contact.cshtml.22013bb9.xighmhow.dll', Symbols loaded.
'iisexpress.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\b63f8236\6775085d\App_Web_contact.cshtml.22013bb9.cv5hktkf.dll', Symbols loaded.
'iisexpress.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\b63f8236\6775085d\App_Web_statuscode.cshtml.22013bb9.1o77hs8i.dll', Symbols loaded.
'iisexpress.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\b63f8236\6775085d\App_Web_statuscode.cshtml.22013bb9.jja-77mw.dll', Symbols loaded.
'iisexpress.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\b63f8236\6775085d\App_Web_location.cshtml.22013bb9.l_e9ev_s.dll', Symbols loaded.
'iisexpress.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\b63f8236\6775085d\App_Web_location.cshtml.22013bb9.b4n59gom.dll', Symbols loaded.
In the above, I've got three DisplayTemplates: "Contact", "Location", and "StatusCode". It appears that IIS is loading symbols twice for each time the display template gets called. Thus, if I'm displaying a table of 100 entries that call all three of these display templates, it's 600 separate symbols loaded.
This isn't a fast operation either. The log files that IIS generates take about 200 ms for each symbol to load. Thus, super-long delays.
What I've Tried:
Debug or Release version, it doesn't matter.
Putting my project on a full IIS implementation on a web server runs it super fast with no problems.
Cassini, IIS Express 7.5, and IIS Express 8.0 all have the problem.
Delete All Breakpoints does nothing.
Clean Solution, or deleting the .suo also do nothing.
If I repair IIS Express/ delete the My Docs\IISExpress folder, or repair/reinstall Visual Studio → the issue MAY go away, but only for a while before it comes right back.
Any advice at all is appreciated.
To answer more questions, yes my machine definitely has horsepower. The infuriating thing is that the same project, with NOTHING altered, can sometimes load very quickly, typically after I repair IIS Express and delete the My Docs\IISExpress folder. Eventually, "something" happens and it's down to 2 minutes to load again. What I'm working on is not a complicated project. No external libraries or dependencies and my VS.NET has no add-ons whatsoever.
Of note, this machine has Symantec Endpoint Protection, which has a history of causing havoc. But disabling it outright (it's good to be an administrator) did not fix the problem.
I have a theory at this point. I'm thinking this is all because I'm working off a redirected folder off a network share. While the debugger was going through its hundreds of "loaded symbols" lines, I paused to see what it was doing. It was in my code, loading the DisplayTemplate I had. Stepping into the template output this:
Step into: Stepping over non-user code 'System.Threading.WaitHandle.InternalWaitOne'
Step into: Stepping over non-user code 'System.Threading.WaitHandle.WaitOne'
Step into: Stepping over non-user code 'System.CodeDom.Compiler.Executor.ExecWaitWithCaptureUnimpersonated'
Step into: Stepping over non-user code 'System.CodeDom.Compiler.Executor.ExecWaitWithCapture'
Step into: Stepping over non-user code 'Microsoft.CSharp.CSharpCodeGenerator.FromFileBatch'
Step into: Stepping over non-user code 'Microsoft.CSharp.CSharpCodeGenerator.System.CodeDom.Compiler.ICodeCompiler.CompileAssemblyFromFileBatch'
Step into: Stepping over non-user code 'System.Web.Compilation.AssemblyBuilder.Compile'
'iisexpress.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\b63f8236\6775085d\App_Web_statuscode.cshtml.22013bb9.bciuyg14.dll', Symbols loaded.
Step into: Stepping over non-user code 'System.Web.Compilation.BuildManager.CompileWebFile'
Step into: Stepping over non-user code 'System.Web.Compilation.BuildManager.GetVPathBuildResultInternal'
Step into: Stepping over non-user code 'System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert'
Step into: Stepping over non-user code 'System.Web.Compilation.BuildManager.GetVirtualPathObjectFactory'
Step into: Stepping over non-user code 'System.Web.Mvc.BuildManagerWrapper.System.Web.Mvc.IBuildManager.FileExists'
Step into: Stepping over non-user code 'System.Web.Mvc.VirtualPathProviderViewEngine.GetPathFromGeneralName'
Step into: Stepping over non-user code 'System.Web.Mvc.VirtualPathProviderViewEngine.FindPartialView'
Step into: Stepping over non-user code 'System.Web.Mvc.ViewEngineCollection.Find'
Step into: Stepping over non-user code 'System.Web.Mvc.ViewEngineCollection.FindPartialView'
Step into: Stepping over non-user code 'System.Web.Mvc.Html.TemplateHelpers.ActionCacheViewItem.Execute'
'iisexpress.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\b63f8236\6775085d\App_Web_statuscode.cshtml.22013bb9.kwj3uqan.dll', Symbols loaded.
Step into: Stepping over non-user code 'System.RuntimeType.CreateInstanceSlow'
Step into: Stepping over non-user code 'System.Web.Mvc.DependencyResolver.DefaultDependencyResolver.GetService'
Step into: Stepping over non-user code 'System.Web.Mvc.BuildManagerViewEngine.DefaultViewPageActivator.Create'
Step into: Stepping over non-user code 'System.Web.Mvc.BuildManagerCompiledView.Render'
It looks like Visual Studio is recompiling my display template every time it's called, which is again, hundreds of times. My theory is that Visual Studio compiles the file, saves it to the network share, then somehow stamps a new time on it, and Visual Studio then thinks the file has changed. Thus, Visual Studio recompiles it yet again. Only a theory though; I really have no clue.
For one, apparently, I have offline files (this is a desktop computer in an office; I couldn't care less). I'm going to disable, reboot, and retry tomorrow.
Plus, moving my project, as is, to the local C: fixes it. It loads very quickly. But this is not ideal in a work environment. I lose Previous Versions, my code isn't backed up at all unless I manually copy it, and it's no longer shared with anyone.
I can make do with copying it back and forth from C to the network share if it comes to it. It's much more annoying to wait two minutes for every page to load.
Here is how I solved the "slow symbol loading" problem in Visual Studio 2012:
Go to Tools -> Options -> Debugging -> General
CHECK the checkmark next to "Enable Just My Code".
Go to Tools -> Options -> Debugging -> Symbols
Click on the "..." button and create/select a new folder somewhere on your local computer to store cached symbols. I named mine "Symbol caching" and put it in Documents -> Visual Studio 2012.
Click on "Load all symbols" and wait for the symbols to be downloaded from Microsoft's servers, which may take a while. Note that Load all symbols button is only available while debugging.
UNCHECK the checkmark next to "Microsoft Symbol Servers" to prevent Visual Studio from remotely querying the Microsoft servers.
Click "OK".
From now on, symbol loading should be much faster.
Note that if you make any changes/downloads to Microsoft assemblies, you may need to go back into the Symbols dialog box and "Load all symbols" again.
Turning off intelliTrace fixed this for me.
In Visual Studio, Tools -> Options -> IntelliTrace
Then, uncheck the checkbox for "Enable IntelliTrace".
None of this worked for me but I found a Breakpoint on a symbol that was deleted. Seems 2010 was hanging on it. To see if this is your issue do debug->windows->breakpoints If any are in there just delete them.
Saunders, mentioned he checked for that but it was not mentioned in the solutions for this problem. Maybe common knowledge for some, but not all of us.
I deleted the "Temporary ASP.NET Files" folder and my localhost page load improved dramatically. Here is the path... %temp%\Temporary ASP.NET Files\
I experienced the same problem and tried most of the resolutions above. Simply deleting cache and temp files end up working for me.
Try removing the contents of these two folders:
C:\Users\\{UserName}\AppData\Local\Microsoft\WebsiteCache
and
C:\Users\\{UserName}\AppData\Local\Temp (in particular the iisexpress and Temporary ASP.NET Files folders).
This can be set up to happen automatically on logging on to Windows by adding a cmd file to the C:\Users\\{username}\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup folder with the following content:
rmdir C:\Users\\{username}\AppData\Local\Microsoft\WebsiteCache /s /q
rmdir C:\Users\\{username}\AppData\Local\Temp /s /q
Do you have enabled FusionLog?
My VisualStudio was very slow to start, open solution and load symbols when start debugging. It was slow only on my machine, but not on other machines.
FusionLog writes tons of log stuff to disk. Just disabling it on RegEdit solved everything, on my case.
This is the FusionLog key on registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion
Check ForceLog value (1 enabled, 0 disabled).
I think I may finally at least know the cause, though not the reason why. When the problem started occurring again, I noticed a ton of "conhost.exe" processes orphaned. I would close Visual Studio and they would remain open. Ending task on each of them has finally, reliably solved the problem. [hopefully]
(Just note, conhost.exe isn't a Visual Studio process though Visual Studio uses it. Thus, other users out there may have other applications out there that run conhost.exe. I know my machine doesn't which is why I can safely end task all of them but YMMV.)
As to why this happens? It seems to occur when I open more than one project at once, which I tend to do often, even though I only build and debug one of them at any time.
Edit #1 - This isn't a "silver bullet" unfortunately. It doesn't always work for me. Typically, when things get slow, I just close all of my Visual Studio sessions, then go into the task manager and end any instance of it, conhost.exe, iisexpress.exe Microsoft.VisualStudio.Web.Host.exe and MSBuild.exe I can find.
Typically, after that, when I restart my project it'll then load quickly. But not always.
Really I think the best course of action is probably to not build & debug code off a redirected folder/network share.
Edit #2 - Two years later, and this is still an issue for me in Visual Studio Community 2013, but I did seem to at least find the culprit task: Explorer.exe. Yeah, who knew. The moment I end that task, bam, page loads in a single second.
If I have a Windows Explorer file browser open to my redirected network drive (which is often since that's where my code is), this problem seems to occur. Closing the window isn't enough, I have to kill the whole Explorer.exe task. I could only guess what it's doing...going nuts with file handles?
I can usually use the task manager to start up a new explorer.exe task (I can only take so much alt-tabbing), and Visual Studio will continue to load nice and quick. But if I so much as open Windows Explorer again, it almost always goes back to super-slow-mo.
So, if you've got a redirected network share, give it a shot. It sure beats working locally.
The above are all good solutions and I tried all of them, but got the solution here, which is to
Debug -> Delete All Breakpoints
For me it was IE 9.08.8112.16241. As soon as I used Firefox or Chrome there was no sluggish debugging with F10 or F11. I do not know what the problem with IE is but I officially despise using it for testing now.
Update: I have turned off all IE program add-ons and it is back to full speed. Turning them on one at a time revealed that LastPass (in my case) was the culprit. I guess I do not get to blame MS after all.
Several years into the future...
If you are using Brave you can easily access your extensions and turn them off one at a time (or several) while debugging.
brave://extensions
Just click the toggle slider. Notice that all of mine are on except for DuckDuckGo Privacy essentials. They are not removed, just temporarily disabled.
For me, I implemented this tip which basically drastically improved performance by adding the following two attributes to compilation tag in web.config
<compilation ... batch="false" optimizeCompilations="true"> ... </compilation>
What does batch="false" do?
It makes pre-compilation more selective by compiling only pages that
have changed and require re-compiling
What exactly is the optimizeCompilations doing? Source
ASP.NET uses a per application hash code which includes the state of a
number of things, including the bin and App_Code folder, and
global.asax. Whenever an ASP.NET app domain starts, it checks if this
hash code has changed from what it previously computed. If it has,
then the entire codegen folder (where compiled and shadow copied
assemblies live) is wiped out.
When this optimization is turned on (via optimizeCompilations="true"), the hash no longer takes into account
bin, App_Code and global.asax. As a result, if those change we don't
wipe out the codegen folder.
Reference: Compilation element on MSDN
I had execution perfomance troubles with debugging too and i tried very many options of debugger. In my case huge perfomance achieved when i change this options:
Tools - Options - Debugging - Output Window - (General output settings - All debug output) - OFF
I had problems with slow Visual Studio debugging when "Native Code" debugger was enabled. Try disabling it.
On "Visual Studio 2012" go to:
Project Properties ->
Web ->
Debuggers (bottom of page). ->
Disable all except ASP.NET
Hope it helps.
Similar questions: 1, 2
In my case, it was the .NET Reflector Visual Studio Extension (version 8.3.0.93) with VS 2012. Debugging was taking 10 seconds for each Step Over (F10).
In Visual Studio, go to Tools/Extensions and Updates... and disable the .NET Reflector Visual Studio Extension. Don't forget to restart Visual Studio.
In my case it was
Tools/Options/Debugging/General/Enable JavaScript debugging for ASP.NET (Chrome and IE)
Once I unchecked this, my debug start went from 45-60 seconds down to 0-5 seconds.
One time, after a power outage, I had to face the same slowness problem each time a breakpoint was hit or a Exception was thrown.
I had the vague remembering that the "suo" file (in the same directory as the "sln" solution file) can be corrupted and make everything slow down.
I deleted my "suo" files and everything was ok. The .suo files deletion is harmless and only implies to recreate my windows layout plus the starting project and a few other non critical customizations.
I was also facing this issue, 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.
I don't know if you're still having this issue, but I debug sites in Visual Studio by attaching the debugger to the process itself rather than letting VS do it for me and I have found it to greatly improve times. I use an extension for VS called AttachTo and I have a small article on how I use it here.
I hope this helps.
My slow VS issue was resolved by disabling the Browser Link
If someone notices this behavior coming out of left field, check to make sure you don't have any breakpoints set in web.config. I must have set one with a stray mouse click, and it really slowed down all debug operations.
After spending all day waiting for symbols to load as slow as turtle speed, mixing and switching between all the possible combinations: Just My Code, Caching symbols, Intellitrace, Just-In-Time, killing processes, etc.
My solution was actually to disable the antivirus. Yeah, Windows Defender was slowing my project launch! It would check all the dlls as Visual Studio requested them and slowed the whole symbol load process.
I have to say our machines have great specs to compile the solution really fast, so that was never a problem. We code in VS 2013 Ultimate.
Emptying the symbol cache worked for me.
See: menu bar / Tools / Options / Debugging / Symbols / Empty Symbol Cache
In Visual Studio:
Tools -> Options -> Debugging -> Symbols
Choose "Only specified modules". Click the "specify modules" link, and add a blank module (click the new document button and hit OK).
to Clear cache etc. use Options 1 & 2; for settings/troubleshooting Options 3 & 4, enjoy!
Option 1: Navigate to IIS express , clear cache and sites
cd "C:\Program Files (x86)\IIS Express\"
run this appcmd.exe list site /xml | appcmd delete site /in
run this Del /S /F /Q %temp% - to clear the Userprofile Temp folder.
run this Del /S /F /Q %Windir%\Temp
Also, clear your temp files in %temp% and logout, or reboot
this clears the Windows temp folder. This will delete all the sites, enjoy!
Option 2: remove/recreate the temp folders
Cmd> rmdir C:\Users\\{username}\AppData\Local\Microsoft\WebsiteCache /s /q
Cmd> rmdir C:\Users\\{username}\AppData\Local\Temp /s /q
Option 3: JMC (Just My Code) Option from MSDN
To enable or disable Just My Code in Visual Studio, under Tools > Options (or Debug > Options) > Debugging > General, select or deselect Enable Just My Code.
Option 4: configure the Visual Studio/Disable Common plugin issues
Even more Visual Studio settings
You can also configure the Visual Studio and disable resource-killing features on the environment, cant remember where I got this, but threes some more I will post shortly.
Environment -> General
Uncheck “Automatically adjust visual experience based on client
performance”
Uncheck “Enable rich client visual experience” Check
“Use hardware graphics acceleration if available”
Environment -> AutoRecover
Uncheck “Save AutoRecover information every”
Environment -> Documents
Check “Save documents as Unicode when data cannot be saved in codepage”
Environment -> Keyboard
Set “ForceGC” to ctrl+num1
Set “ReSharper_Toggle” to ctrl+num0 (if ReSharper is used)
Set “ReSharper_EnableDaemon” to ctrl+num8 (if ReSharper is used)
Environment -> Startup
Set “At startup” to “Show empty environment at startup”
Uncheck “Download content every”
Environment -> Synchronized settings
Uncheck “Synchronize settings across devices when signed into Visual Studio”
Asp.net core debugging was painfully slow because of unknown VS extension had replaced default Just in Time debugger.
I have found such message in the OPTIONS\DEBUGGING\Just-In-Time configuration tab (as warning text).
Another debugger has registered itself as the Just-In-Time debugger. To repair, enable Just-In-Time debugging or run Visual Studio repair.
Description: https://msdn.microsoft.com/en-us/library/ssc8234s.aspx?f=255&MSPPError=-2147217396
Returning back the default JIT debugger (just checked Managed option that was unchecked) solve all my problems.
In my case I noticed that disabling my internet connection would make it run as fast as with ctrl-f5, so I went to debug->options->symbols and just unchecked all .pdb locations.
Seems like VS was trying to connect to these servers every time a debug session was launched.
Note that disabling Debug->Options->Debugging->General "Enable source support" or "Require source files to exactly match the original version" wouldn't make any difference.
Similar problem wasted better half of my day!
Since solution for my problem was different from whats said here, I'm going to post it so it might help someone else.
Mine was a breakpoint. I had a "Break at function" breakpoint (i.e instead of pressing F9 on a code line, we create them using the breakpoints window) which is supposed to stop in a library function outside my project.
And I had "Use Intellisense to verify the function name" CHECKED. (Info here.)
This slowed down vs like hell (project start-up from 2 seconds to 5 minutes).
Removing the break point solved it for good.
One thing that worked for me after doing all the above was:
In the Threads window (Debug->Windows->Threads), set Group by to None. This can only be done while debugging.
This was having an impact even after closing that window.
Open the solution folder in windows explorer, close the visual studio, delete .suo file from windows explorer.
Now open the project in visual studio, hopefully debugger will attached/detached fastly.
For me it was conditional breakpoints. Those seem to really slow things down.
Go to your environment variables and look for the key _NT_SYMBOL_PATH.
Delete it.
Voila, worked like a charm.