(xkcd)
I know that compiling nowadays is much faster than it was before. Yet, for me, it seems that compiling and especially running/debugging ASP.NET projects with the Visual Studio Web Development Server is incredibly slow.
Since the beginning of last summer, I've been working heavily on ASP.NET MVC projects. Of course, the best way to debug them is by using the web server that comes with Visual Studio. When doing that, I get horrendously slow loading times. Chrome dev tools typically report that loading one of my pages had a 3 minute wait time, followed by a short loading time.
I've seen these two questions, but they don't help. While I do most of my debugging work in Chrome, the same happens in IE.
Has anyone else had this problem before? If so, any tips?
Also, I doubt that the problem lies with the speed of my machine. This computer is really fast running Windows 7 and Visual Studio 2010, so I don't see why ASP.NET debugging should be so slow.
UPDATE: In his answer below, Jon Skeet suggested attempting to identify whether the problem is being caused by the environment or by the code itself. I created a brand new MVC project and ran it. The first test appeared to be much faster. However, after testing it a few more times, it's safe to say that the first test was an anomaly - usually, it takes as long as my big project (2 - 3 minutes). Thus, this is a problem with the environment. Thanks in advance for any help!
UPDATE #2: It's been a while since I updated this question. Here are some details I've gathered since my last update:
This delay is occuring on both of my development machines, both running Windows 7 and Visual Studio 2010
This delay is happening for all my MVC2 and MVC3 projects (but I haven't experimented with plain ASP.NET yet)
Plain/vanilla MVC projects experience the same delay as MVC projects with big codebases
Disabling IntelliTrace did not help
Disabling IPv6 did not help
I haven't found a solution for this problem, so I've been stuck with huge wait times. Does anyone know how to solve this?
There's no reason why it should take 3 minutes to start debugging something unless you've got something really strange going on.
I suggest you launch the debugger, try to navigate to a page and then just break into the debugger while it's loading. See where you're losing time. Maybe you're making some call on startup which is failing, but taking minutes to do so.
I've never experienced anything like what you're describing, which suggests it's either in your environment or in your code - and if it's a generally fast computer, that suggests it's somewhere in the code.
If you create a brand new MVC project and debug into that, does that take a long time?
You might also want to run Wireshark when you start debugging - see whether something in your app is trying to fetch a network resource of some description without you realising it.
This is due to the IPv6 DNS problem within Firefox and can be fixed by setting the network.dns.disableIPv6 setting to true within the about:config
Slow DNS response - Firefox on localhost and Visual Studio or Cassini
This is actually a known performance issue with MVC, caused by throwing a ton of exceptions internally on startup. If you have IntelliTrace turned on, this will wreck havoc with it. Try disabling IntelliTrace and see if that improves it at all.
Source: http://connect.microsoft.com/VisualStudio/feedback/details/535799/debugging-mvc-is-very-very-slow
Check out if this helps:
http://blogs.msdn.com/b/mahuja/archive/2008/07/08/resolving-very-slow-symbol-loading-with-vs-2008-during-debugging.aspx
I met the same problem these days, working under Win7, VS2010, and developing a Silverlight solution with 10+ projects. It takes about 3 minutes to launch IE, and waits 3 minutes to get back VS after closing IE. I overcame the problem by trying different ways. But the only valuable method:
Unload all projects not for debug
Start debug the solution (it works normal )
Reload other projects
VS works normal here. (VS works normal)
It seems the problem is just related with the VS environment on my side. It has nothing to do with ASP.NET Development Server or IIS.
I was having the same problem. It ended up being a problem with ColdFusion being installed on my local machine (as painful as it is for me to admit). ColdFusion puts Handler Mappings named AboMapperCustom-* that were causing the latency. I uninstalled ColdFusion because I no longer need it (thank God). Another solution could be to remove each AboMapperCustom entry through the web.config. Example:
<handlers>
<remove name="AboMapperCustom-15397" />
<remove name="AboMapperCustom-20358" />
<remove name="AboMapperCustom-47286" />
</handlers>
Make sure the 5-digits following AboMapperCustom- match those in your local IIS Handler Mappings.
HTH
On Visual Studio 2012 + Win10 x64, i've noticed that if you
go to the taskbar and find the asp.net dev server there,
right click it and do a "show details"
close the box (NOT 'stop', just close via 'x')
then the server loads almost instantly
Related
I've got stumped by problem during development of my ASP.NET application.
I cannot debug it any more after attaching debugger to a process. Recently I was changing some windows features and checking IIS settings but as far as I remember I was able to debug my app till today.
Ok so what's going on.
I attached debugger and nothing happens no symbols are getting loaded (I am absolutely sure that Build -> Configuration and stuff looks correct in terms of debug etd). That symbols are getting generated and that app is working on dlls which I compile the only problem is that no matter what I do - symbols are not getting loaded.
I've got 2 traces which could lead me to the cause 1st:
The first one is strange application type when attempting to attach a debugger using visual studio. Normally all other apps are using Managed (v4.0......),x64 (I am right now talking about Window with all process running on computer Debug -> Attach -> type column)
but this app for some reason is using Script, Managed (v4.0......),x64
The other one is that when I've debugger attached to the application and open Debug -> Windows -> Modules the only one that is listed is:
**Script Code (Microsoft Active Server Pages) Script Code (Microsoft Active Server Pages) N/A N/A Symbols loaded. Script Code (Microsoft Active Server Pages) 1 [29896] w3wp.exe**
Which kinda looks like some precompilled stuff. (I do not recall enabling any kind of recompilation).
I've tried recreating app on IIS along with switch app pool yet it's still the same. What's even more after checking diff of web config I don't see any kind of change which could lead to such behavior.
I was working with this application for like 8 months and never had a problem like this.
Thanks in advance for your tips.
Kind Regards.
EDIT:
Images
Modules
I've had the exact same issue and could solve it by moving the site to a different application pool. The target application pool already had an application assigned which I could debug (showed up as Managed (v4.0......),x64 in process selector) and once I moved the problematic site over, I could also debug that site.
I didn't figure out what exactly causes the behavior in the first application pool but maybe this helps someone to quickly solve this problem until someone comes up with a better analysis.
Is there one kind soul out there who has the time to help me figure out why my application is intermittently hanging (and hopefully how to fix it)? I'm running a web program from VS2015 that accesses a SQL Server database. Sometimes I'll click on a link on my webpage and everything works fine. Other times, though, the little circle just spins forever, and it never comes back. It doesn't seem to be related to the database because one time I caught it hanging on a call to XmlSerializer serializer = new XmlSerializer(type);
I'm running the website in IIS Express on localhost on a Windows 10 laptop (16GB & plenty of disk). I also have ReSharper if anyone thinks that can help me diagnose the problem. I've been fighting with this for days and have no idea what else to do but hope that someone here will have pity on me.
Re: D Stanley's comments: "Do you have any logging? Can you run it in the debugger to see where it's hanging? Is there anything in the system event logs?"
There is logging, but only on caught exceptions. Nothing that will help the hang situation. I can run it in the debugger, but when it's hung I can't see where it's hung (it's in External Code). The Event Log does report a "perflib" error when I run the program. I can post that info if you think it would help.
More info. I installed Fiddler. When the application is hung, Fiddler is still going to town. The "Process" it's showing is "scriptedsandbox64", which is doing I/O and consuming CPU time.
I suggest you add lots more log messages to your code, something like:
DateTime.Now.ToString("o") "Starting xxx"
DateTime.Now.ToString("o") "Finished xxx"
where xxx is a name for some chunk of code. You suspect the problem is in external code, so wrap all those calls.
You can then see where the application spends excessive time. Once you have found the right area, then perhaps add more logging to focus in on the problem.
The answer to my hanging problem was to use Local IIS instead of IIS Express. Once I figured out how to set up the website for localhost and began running with Local IIS my hangs disappeared.
I have a strange issue that occurs every day. I have recently been given a fellow developers laptop with Windows7 & IIS6 (they've left) and my previous laptop (WidnowsXP & IIS 5) has been recycled into the system, so I'm stuck with this one and didn't originally set up the system. Developing worked fine on my old computer, but on this one.
I am developing an ASP.NET website and after a while of editing, building, then going to localhost in IE, the page doesn't show. The process w3wp.exe isn't in my list of processes in the task manager. If I call iisreset.exe, this usually fixes it at first (i.e. going to localhost starts w3wp.exe and after a short while my page appears).
After a few runs of this, even this fix doesn't work, but I've found that if I close IE, then run iisreset.exe it fixes it.
Then after a few runs of this, I also have to close Visual Studio & IE, then iisreset.exe. Once I get to this stage, I can't make a single edit in visual studio without having to close it to run the web page. Note, I'm not running in debug mode. I've even tried editing in notepad++ for simple edits and I have to close that too before iisreset works!
Eventually I end up restarting my computer because these incantations stop working. I'm at the end of my tether. Does anyone know what could actually be wrong or where I should start looking for a real fix?
I have a Silverlight project that we use internally that I wrote - and since we've not had any need to work on it, it's been a while since I've opened the project. I opened it up this morning and everything is fine in terms of building, but whenever I try to debug I get the following error:
Unable to start program "http://mymachinename/mywebsite/index.aspx"
Of course, running it in Firefox works fine but no symbols are loaded. Running without debugging still throws the same error but IE loads up anyway...
Navigating to the website in IE works fine - SL app opens up, loads data etc etc, all looks good
I've Googled this all morning (usually quite good at finding info) and been through all the questions on SO and I can't figure out what's going on - there doesn't seem to be any messages in the event log, there are no messages in any VS output window, the w3wp just terminates immediately after starting (probably due to there being an error trying to open IE). I've tried reinstalling IE, cleaning/rebuilding, using local dev server, creating a new web project, turning on/off settings in IE9 etc etc
Nothing seems to make a difference - anyone got any experiences of this and has fixed it without doing one of the things I've already done? Any other suggestions?
Thanks in advance!
UPDATE
Just to be clear in case anyone asks - I get this problem when creating a new web project - i.e. everything I said I'd tried (above) didn't change the behaviour. It showed the same error no matter what I'd done so far (that includes a NON SL web project)
I've also tried attaching the debugger to w3wp that is running (the standard IIS process) and I can't seem to get it to debug (no symbols are loading), but that might be another issue altogether. I'm going to look at that next and maybe if I figure that out it might lead to fixing this issue
UPDATE 2
Debugging in Firefox works - I attached to w3wp with no success, then realising my stupidity (SL being a client side app!) I attached to the plugin-container.exe that FF runs its plugins in. This works. I can probably do the same for IE and just attach to IE, but why won't it start up from VS?! hair pull
UPDATE 3
Just in case anyone asks, the default browser is set to IE in VS. Also I've managed to debug by attaching to IE, it just won't start IE from within VS - annoying but I can live with it for now. If anyone does have a suggestion though, feel free...
For anyone's information in case they have this same problem, it ended up being that the port I was running my site on was also running a SharePoint site!
I created a new site on port 81 and used that for dev - not sure what setting on the other site caused the issue but it ended up working on port 81.
For me Visual Studio 2010 professional responds very slowly when I use it for WPF developement. It does not happen as soon as I open the solution, but after i continuously use for some time with WPF related activities like coding, debugging, switching between different wpf views etc. After some time everything get slow like ctl+ tab, right click, typing everything...
Btw my system is of decent configuration.
quad processor with 4 GB of RAM
Any idea why it happens or if anybody else facing same problem?
The designer is a little slow and various plugins to VS2010 can also slow down performance.
however, one thing to note is that VS2010 actually runs your code when you open the designer. i had a project where the developers added a bunch of threading and logic to the forms that ended up geting run by the designer, causing poor design time performance.
VS does have some ways of preventing this from happening, for example, the normal constructor is not run at the design time, but some things will run such as variable instanciations for example.
What you can do is launch another VS instance and attatch the debugger (Debug > attatch to process) to the first VS instance. you can then break the execution of the first instance and see if any of your code is beeing run by the designer.
It may be unrelated, but check for two things:
1 - Disable hardware acceleration. I had an horrible time with visual studio, not being able to type and all, until I disabled it.
2 - If you happen to have unwanted VirtualBox/VMWare plugins, they may be hogging up everything.