IIS 8 as localhost development server: Long refresh times - asp.net

I have IIS 8 on my workstation. I'm building ASP.NET applications and I continuously encounter extremely large reload times. I've set debug to "false" in web config files. I don't know what else to check. I'm working in visual studio. I know the reload time is longer if I 'build' my project but this is happening even when I'm changing markup. I am also using dropbox as my web root. Other developers are doing this as well and they aren't encountering this issue.
This issue is isolated to Chrome. I'm not experiencing long refresh times in Firefox or IE. Also, this only applies to localhost. Everything else in Chrome is very quick.

Is it possible that the application pool is timing out and has to spin back up for the next request? The default timeout is 20 minutes.

Related

IIS 10 on WinServer 2019 is loading asp.net pages very slow even on subsequent loads

My question has nothing to do with the initial page loads. My ASP.NET Web Site is running very slow, on IIS 10. Even when I refresh the page after a load, it takes minutes. What do I need to check?
Application Initialization Module is installed and running
App Pool is using Classic managed Pipeline mode and has Start-Mode set to AlwaysRunning
Preload Enabled in Website's setting is set to true
The same application runs fine on another server running older WinServer and IIS 8. What do I need to check?
This is embarrassing. Posting this answer so I find my own question the next time I run into this again, or someone else runs into this. My application on the other server where it runs, has caching configured so all the database pulls are cached. This new server has no caching set up. Those pulls are so slow, I am finally getting the hang of it.

Easiest way to run/debug ASP.NET Core app

I just upgraded my ASP.NET (Framework) MVC app to ASP.NET Core 2.2. That process was painful enough, however even more painful is running the web app locally.
Issues with running in IIS Express:
If I launch the app with F5 (to enable debugging), then once I stop debugging the browser window closes so I have to start over on the homepage each time after changing any code.
If I launch the app with Ctrl + F5 (no debugging), after a few rebuilds the website seems to die, meaning that any new page requests just say host not found. I then have to Ctrl + F5 again to get it going again, but then I'm back on the homepage.
Visual Studio 2019 sometimes decides to launch the webpage in my existing Chrome window on a new tab, but sometimes decides to launch it in an entirely new Chrome window. After several minutes of dev, I'm left with multiple tabs and windows open.
Issues with running in IIS:
The only way it runs is if I manually edit my Web.config to have the proper values for processPath ("dotnet") and arguments ("./bin/Debug/Housters.Web.dll"). Visual Studio likes to inject in aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" every time I build or run my app, despite me having IsTransformWebConfigDisabled = true in my .csproj. So I constantly have to go into git and revert these changes, or else my app will fall back to the dreaded ANCM In-Process Handler Load Failure page.
Assuming the Web.config has the proper values, after running the application in the browser I can no longer build the project. Instead it gives the error: Error MSB3027 Could not copy "obj\Debug\netcoreapp2.2\Housters.Web.dll" to "bin\Debug\Housters.Web.dll". Exceeded retry count of 10. Failed. The file is locked by: "IIS Worker Process (15496)". IIS is using the ASP.NET Core web app's dll so I can't actually update my code and build it, that's just great. The workaround is to recycle my IIS app pool, but this gets old REAL quick when you need to do it before every single rebuild.
Attaching to the w3wp.exe process isn't causing any breakpoints to be hit, so I can't debug under IIS (IIS Express debugging works fine.)
The launch profiles that I configured in launchSettings.json are ignored. For example, when I choose my IIS launch profile (which has "http://localhost" as the launchUrl and applicationUrl), if I F5 or Ctrl + F5 it opens "http://localhost:62551/" in the browser window.
So this begs the question, how are others developing/running/debugging their ASP.NET Core apps on their local dev machines? Maybe most web developers have moved away from ASP.NET to purely javascript frameworks like Angular, React, and Vue so I'm just out of luck? Or am I missing something that will make ASP.NET Core development less painful?
Currently, the experience with ASP .NET Core has greatly improved compared to the past.
However, certain glitches still remain. For what regards IIS Express (in production we use Kestrel), you can try these things with Visual Studio 2017 and 2019 (they work for us):
If I launch the app with F5 (to enable debugging), then once I stop debugging the browser window closes so I have to start over on the homepage each time after changing any code.
Just don't use the page: let the tab/page open, spawn another tab/page and use the latter for debugging. This way your session is going to be as similar to a production environment. We have Firefox as default browser, but we usually debug with Chrome, therefore, not touching the process spawned by Visual Studio keeps IIS Express alive.
If I launch the app with Ctrl + F5 (no debugging), after a few rebuilds the website seems to die, meaning that any new page requests just say host not found. I then have to Ctrl + F5 again to get it going again, but then I'm back on the homepage.
It seems that cleaning the whole solution twice solves the issue (at least for us). The first time you clean the solution, IIS Express still serves the site. Apparently, this should be the designed way (cannot find the documentation about that).
If that does not work, it might happen that a Visual Studio service is stuck. In this case, shut down Visual Studio (I know, it's painful), wait a little bit, and kill all the dotnet.exe currently running after verifying they are part of Visual Studio.
Visual Studio 2019 sometimes decides to launch the webpage in my existing Chrome window on a new tab, but sometimes decides to launch it in an entirely new Chrome window. After several minutes of dev, I'm left with multiple tabs and windows open.
This is partially what I said previously. Although painful and resource expensive, having multiple windows open allows us to survive.
For reference, we use the very same configuration on debug and release (with kestrel).

Angular 4 - Page Unresponsive After Deploying to IIS 10

While the app works perfectly in the DEBUG mode, most of the time, it hangs or shows Unresponsive Page error in chrome.
I haven't test it in other browsers because what I've written won't work in other browsers at all.
Unfortunately have no idea how I can monitor requests in IIS.
I should say that both Server App and Angular 4 App are hosted on the local IIS v10 with individual application pools.
I already used --enable-logging --v=1 --vmodule=metrics=2 command when starting google-chrome, but I guess nothing important are being saved in chrome_debug.log file or at least I can't read it.

VS2010 Debug web app causes "cannot start application" and "access denied" errors

When I try to debug my VS2010 web app (F5), the IE web browser windows pops up but then freezes, and my VS2010 IDE window pops up an error message:
Unable to start program 'http://localhost:nnnn/Login.aspx'.
Access is denied.
I'm running VS2010 (10.0.30319.1), targeted to ASP.NET 4.0 (4.0.30319), in non-administrator mode, with ASP.NET debugging enabled, on 64-bit Windows 7 Enterprise SP1, with IE 9 (9.0.8112.16421 with update 9.0.29).
This web app and others I work with have been working just fine for several months, but they all started to misbehave in this manner a few weeks ago. At first, the first time I tried to debug (F5) I'd get the error, but after clearing it and closing the IE window and trying F5 again a second time, the browser would come up just fine. I assumed it was just some glitch, so I tolerated it.
Lately, though it has gotten worse, to the point that 90% of my attempts and re-attempts to debug the web app cause a hung browser and the error. It sometimes works, but most times it doesn't. I have to kill the handing iexplorer.exe processes to clean up my user space, otherwise I eventually get a message about not having enough files to start the browser. I try rebuilding, stopping the ASP.NET Development Server process, even exiting VS2010 and restarting it, but I can't seem to find the magic sequence of events to get it to work.
If I start without debug (Shift-F5), it works, but two IE web browser windows are opened, and both attach to the web app. I don't know if this is related to the first problem. And needless to say, this does not really allow me to debug my code. I tried attaching to either of the IE processes, but I still could not get the debugger to actually debug the executing app. (There is a message about no symbols being loaded for the attached process.)
Most of the solutions for this problem I've found say something about running with administrator access. I cannot do this, however; I work at a large financial company, and developers are not allowed to have local admin rights on our PCs. I don't control system patches, but I can request Help Desk ticket to resolve the problem; but I'd like to resolve this problem myself if it is a fairly simple configuration problem on my part.
Addendum
I should also add that I am not using IIS (because I don't have it installed on my system, and I can't use it anyway because I don't have local admin rights), but instead I am using the built-in Visual Studio Development Server. I've also selected a specific HTTP port number for it to use. Also, all of the directories I'm been using were created by me (as part of my project workspace), so there should be no access permission problems.
Like I said, I can sometimes get a debugging web session started, but most of the time I can't. So whatever is causing this problem, it is probably something intermittent.
This tend to occur when you try to run the full version of IIS rather than the Visual Studio Web Server or IIS Express. Have you tried running IIS Express instead? I think there's support for IIS Express that came with one of the later updates to VS 2010?
IIS proper definitely requires full admin rights in order to attach a debugger because full IIS runs under a system account rather than your own account. IIS Express (as well as the Visual Studio Web Server) however should run under your own user account and so debugging should work on the local machine even with a non-admin account.
One issue that might cause problems is directory permissions. Make sure that the folder where your Web files live are read/execute accessible through the file system for your user account.
Finally make sure you don't have some other instance of a Web service running on the same HTTP port.
I am having the same issue, it works when i don't choose to debug but CTRL+F5 to start it. F5 Debugger al

Devexpress grid slow reponse after idle

I'm using devexpress gridview on developing application that users have to view group of row data,my application works fine on development server of visual studio 2010 but when i deploy the application on iis 7.5 performance issue become clear.
when page is loaded on IE for the first time ,application respond normally and ajax calls respond fine,but when application became idle for awhile*(approximately less than 5 minutes)* ,ajax calls responding issue appear (takes 20 seconds for a single request).
note that:
-i review all application pool configurations on iis.
-i notice that when i use Firefox application respond normally but unfortunately i need to use it on IE.
-when i deploy the application locally from my machine (Local IIS) application respond normally.
could any one help please
If you're saying that the response time in Firefox is good then the issue is not IIS.
Devexpress controls are heavy on client (javascript) and can cause delays in page loading (especially if you use jQuery)
I suggest to:
create a test page that has nothing other than the gridview on it.
Enable client script debugging (in IE options)
use IE developer Profiler to see any client errors

Resources