Short version:
When I debug ASP.NET MVC apps in VS2013 and try to edit razor views or css files, the CPU usage of devenv.exe skyrockets to the point where VS becomes unresponsive. Browser link is turned off, yet this still happens. Restarting debugging doesn't help, restarting VS doesn't help, restarting windows helps only for a short while, before the problem shows up again. How do I fix this?
Long version:
I'm having some trouble with Visual Studio 2013. Namely, after I start debugging an ASP.NET MVC app devenv.exe starts hogging CPU (to the point where Visual Studio becomes unresponsive). Some time ago this was happening only from time to time, but now it happens nearly always.
At first I thought that it was a problem with Browser Link, but the problem didn't go away after I turned it off and closing the browser while debugging doesn't have any effect.
Stopping debugging makes it stop hogging CPU, but it doesn't make the problem go away when I debug the app next time. Restarting VS doesn't help either and restarting Windows only helps for a little while.
The main clue here is that devenv.exe shows low CPU usage while VS window is not active. Switching to VS window makes devenv.exe use more CPU, but trying to do anything in VS (especially editing a razor view or css file) makes the CPU usage skyrocket.
Anyone got an idea what could be causing this problem and how to solve it?
Being unable to edit css and views while debugging is seriously lowering my productivity (the app takes good minute or two to start).
P.S. The app I'm working on right now is a nopcommerce based shop, but I had this problem before while debugging MVC apps that had nothing to do with nopcommerce.
I didn't manage to find the source of the problem, but closing all editor windows in VS seems to make it go away. If there are further lag spikes, restarting debugging might be also a good idea.
Since I didn't see this problem in a new project, it might be related to the sheer size of the solution, the number of files being opened in the editor at one time (though the problem remained even when I left one view open), the time those files where opened in the VS (I'm not entirely sure why this would be a problem, maybe it has something to do with the file history).
Related
I've spent the better part of about forty eight hours dealing with this issue. I've read all that is said about it on this forum. (Which isn't much.) And I've read all about it elsewhere. And I still have not found a solution.The problem.
It's simple. My project builds successfully. When I start the debugger, I get the endless blue loading circle. It never launches into the browser.
If you know what the issue is, please do share I would be grateful.
Thanks,
CM
For the record, what worked for me, was running my program in a terminal. Completely bipassed Visual Studio's buggy UI.
I don't know what caused the infinite blue loading circle.
And I don't care.
I'm moving on.
Thanks,
CM
I've been working on an MVC 5 code first project for a few months and (seemingly) out of nowhere, Visual Studio is refusing to debug and giving me some strange errors.
When I try to run the application Ctrl+F5 it builds ok but the browser never gets beyond the loading stage, I still have the pinwheel in the browser tab, but the app never loads.
When I try to debug the applicaiton F5 it builds ok, but then comes up with 2 errors, firstly Debugging information for iisexpress.exe cannot be found or does not match. Cannot find or open the PDB file. and then Process with an Id of xxxx is not running.
I've tried loading symbols from MS (https://stackoverflow.com/a/8138518/1778169), using a different database name, uninstalling VS extensions, performing all Windows Updates, repairing the VS installation and even reinstalling VS entirely. Nothing seems to help.
I'm not very familiar with PDB files, but I have done nothing knowingly to change this, and they seem to be in the right place:
I am running out of ideas, but really want to avoid a Windows reinstall if possible.
It's only happening in this one project, so the problem would seem to be with the project itself, not the installation. But I have no idea where to start debugging this problem, or looking for a solution.
Possibly Relevant
I tried running the app on a custom domain (set up in the hosts file and IIS Express's ApplicationHosts.config file). In an attempt to solve this problem I reverted these settings back to the default localhost:[port]. This doesn't seem to have made any difference, but thought I should mention it just in case.
My problem was that the Native Code box was ticked in the Debuggers section of the Web section in Project Properties.
I don't know how this came to be ticked, I certainly never ticked it.
Either way, unticking this box solved my problem.
When I run my mvc application using Visual Studio 2012 on Chrome, my page takes 36s to render - saw this using mini-profiler. When I host the project on a remote server and hit the server for the page, then it takes 36s on the first hit. But on subsequent hits, it dramatically reduces to 1s or less. Any thoughts on why this might be? On the remote server, when we restart the application pool, we are seeing it take 36s.
So question is, is it taking that long because of IIS allocating resources to the site or is there something else wrong with our setup? Our development time is really taking a hit with the amount of time that it takes each time we have to debug our project. Build and then takes 36s each time to render the page we are debugging.
When you say "run", I'm assuming you meaning debug. Debug rebuilds the project and then once it loads the browser, all the standard initialization for a first time load must be done each time. The fact that it takes the same amount of time (36s) as the application pool spin-up on your server seems to bear this out.
FWIW, you only need to debug your project once per Visual Studio session to have IIS Express fire up. Afterwards, you can simply rebuild your project and refresh the browser directly after (without using debug in Visual Studio) to test your changes. And, you only need to rebuild if you made changes to any *.cs files. Razor views, web.config, etc. will reflect their changes on next page load without a rebuild. The only thing you lose doing it this way is the debug ability, obviously enough. You'll just get a standard yellow page of death instead of automatically jumping to the offending bit of code in Visual Studio. But, I've found that unless I actually need to debug, this method is much quicker to develop with.
A few possibilities come to mind:
View Compilation
By default when you work on your project in Visual Studio, the views are compiled on-demand. While 36 sec seems like a very long time to compile the view for the first page, this could be a contributing factor. If your page changes, it has to be re-compiled. To eliminate this as a factor when performing measurements, you can edit your .csproj file with a text editor and change the line
<MvcBuildViews>false</MvcBuildViews>
to
<MvcBuildViews>true</MvcBuildViews>
(this can also be a useful setting in general).
Other Initialization Overhead
If you are doing much initialization when your app starts (perhaps pre-loading some data from a file or database), that initialization must happen every time the web server starts or the app domain recycles. In Visual Studio, I find that the web server can restart at surprising (to me) times. Add some logging to see if you're running startup code during a particular benchmark run, and see how much overhead that is.
Entity Framework
For some reason, Entity Framework runs much slower when debugging. If you're doing a lot of data access through EF, that could account for some of the difference.
I'm developing an application on two different machines (home and work) and while the home one seems to run just fine, the work one is, for lack of a better word, possessed. It has been exhibiting the following issues:
When loading the application, it will start at the simulator's main screen instead of starting the application at random intervals. You can start the application and have it work fine, then close the simulator, reload, and have the same codebase not load.
Going to applications doesn't show the application itself, in fact it never does.
Trying to load the applications cod file (File->load java program) never works. Tried the steps in this thread, with unreliable results.
Extremely small changes, such as modifying the value of a width variable by one, commenting out a function such as makeMenu or adding a button will cause code to no longer work, with no errors shown by the IDE.
Using clear.bat with sometimes work, sometimes not. Same with manually removing all files with the name of the project.
reinstalling the eclipse environment and the blackberry plugin did nothing more then burn off an hour.
having "load on startup" in the blackberry_app_descriptor.xml file is set.
Both systems are using Eclipse 3.5.1, BB plugin for eclipse 1.1 beta, Java 4.5 with the 8300 simulator. THe only difference that I am seeing is the operating system between the two systems. The work one being XP Sp3, home being vista. THe vista one isn't perfect, but I can test variable changes without flipping a coin to see if the app will even load or not.
I've tried the solutions that were similar on this forum, such as this one, but it looked to be that those solutions are dated as none of the options for the steps existed in my eclipse install.
So has anyone ran into such baffling behavior, and can it be fixed? Anything that I might have missed that could be tried?
I've been seeing this behavior with the new 1.1 plugin, the application doesn't load on startup and the FIle->load java program doesn't help. For me, the solution was I have to run a clean build every time, that is the eclipse clean and build instead of just build, not the clean.bat... Hope this helps!
Try clearing resources that have improper naming structure in your projects stuff with spaces or special character in the name of the file.
It took me two days to figure out.
One solution i got regarding your problem.
As I See Please run the application first time as Run as blackberry simulator
that is got start and here pick up run and then Run as Blackberry simulator
When developing WebForms web site, I start my project once, Cassini loads and stays loaded until I kill it. Therefore, when I change something (it recompiles in background), and refresh in browser is all it takes to see the changes.
But with MVC, I have to start debugging every time because Cassini is not responding to requests if debugging is not running.
Is it possible to get the same Cassini behavior in MVC as in WebForms?
It isn't usual for this behaviour, even when developing MVC websites. I am able to make changes to non-compiled stuff (aspx,ascx) etc and it'll take effect immediately on refresh. Changing classes will require you to stop debugging so that you can re-compile, and allow breakpoints to work correctly.
Also, whilst isn't strictly an answer to your question, you should strongly consider moving away from the baked-in Cassini web server used when debugging.
For more information on my general hatred of Cassini, please read this previous question.
If you're unable to either install IIS on your machine (because it might be XP Home or whatever), then you should consider either upgrading to XP Professional (where you are limited to running one website only), or Windows Vista, or Windows 7 RC where you can use IIS7 and all the greatness that it provides.
If you can't do any of those, you should consider trying an alternative, such as Ultidev.
I think I found the solution - the trick is to Run project wihout debugging. There is no item for it in Build menu, but keyboard shortcut works (Ctrl+F5 in Visual Basic keyboard scheme).
Cassini starts and remains responsive regardless of debug mode.