Breakpoints not hit when debug website project after update to VS 2015 Update 3 - asp.net

I have a web project (DNN module) that I am developing and I recently updated to Visual Studio Professional 2015 Update 3.
I am using IIS 10 on a windows 10 PC
When I try to F5 / Debug my app I get the following warning on any breakpoints:
the breakpoint will not currently be hit. no symbols have been loaded
for this document
What I have tried to fix this:
I enabled directory browsing inside IIS 10
I Run VS in admin mode / elevated permission
Updated MS ASP.NET and Web Tools extension to latest version
Updated MS ASP.NET Web Framework and tool extension to latest version
cleared out and re-downloaded all debug symbols
Clean and rebuilt in both release and debug mode
Made sure modules runAllManagedModulesForAllRequests="true" is set in
system.webserver of web.config
Restart IIS / refresh application pools, and restart website
using a different port for the website
obviously restart computer / and visual studio
I am at a total loss and really need help. I can not figure out why my breakpoints are not being hit, when I debug the site no errors are thrown and the site runs fine.
Other Attempts:
From this SO thread I tried:
Install Update for Microsoft Visual Studio 2015 Update 3 (KB3165756)
From This SO Thread I tried:
disable "just my code" in debug general settings
From User suggestions:
I have tried attaching directly to the w3wp.exe process - no breakpoints hit and visual studio crashes when I try to stop debugging. Also, as soon as I attach the debugger, the website stop workings all together
Question
Can someone help me figure out why my break points are not being hit when debugging from visual studio.
EDIT # 1: Additional attempts
When I debug my application and open the Debug -> Windows -> Modules window I do not see the name of my projects dll / pdb file in the list of Modules. I tried going to Debug -> Options -> Symbols and clicking the Load All Symbols button.
I included a screen shot. My dll or project is named krisisShifts so the dll created in the obj/Debug folder is krisisShifts.dll and KrisisShifts.pdb etc. The blue mark on the image shows the dll is not listed in the loaded modules. Also I included the default attached process Visual studio is using to debug the site marked in Red.
I also deleted the site and application pool from IIS and recreated them with different names, site displays fine, but no breakpoints hit
EDIT 2: Attach to process now works
Not sure what I did. I have been fighting with this all day and afer restarting the computer and visual studio numerous times I can now attach to process w3wp.exe and the breakpoints are hit.
However hitting F5 still does not work. The site loads but no breakpoints are hit and I can see that my projects .dll is not added to the debug modules list (but it is when I attach to process).
I feel like I am closer but still can not figure out why my project .dll is not loaded in the debug modules when hitting f5.

Are you able to attach directly to the w3wp.exe process, and if so are your breakpoints hit then?
Menu > Debug > "Attach to process..."
Check "Show processes from all users"
Look for a process named "w3wp.exe", with the username "IIS APPPOOL\{IIS site name}"
Click "Attach"

Related

Opening website from IIS in Visual Studio restarts the website

I have a website in IIS and if I open it in Visual Studio (running as admin) the application pool always restarts - which is a big problem on my live server. Can anyone help me prevent it from happening?
I realise precompiled web applications exist and that RDPing to live server and using VS like that is not ideal but I can't change that right now.
My project is a VB website (no MVC - just .aspx pages) and I use Roslyn and all the new language features so I can't remove DotNetCompilerPlatform (I don't think choice of language or the code has anything to do with the problem). This happens on Windows 10 and Server 2016.
From my investigation I found the following:
It seems VS does SetSecurityFile on every file in /roslyn directory which triggers a NotifyChangeDirectory message. The permissions on the files remain the same - VS updates them for no apparent reason and that rightfully causes a recompile of the website.
I've cleaned out the NuGet package DotNetCompilerPlatform. I've tried applying loose permissions on the project directory (Everyone - Full Control). I've tried VS 2017, 2019 and the new 2019 preview. Nothing helped so far. What I do know is that this didn't used to happen in the past.
Any ideas would be appreciated.
The application pool will not automatically restart unless you set the recycling time or an error occurs, So please check if there are related errors in your Event Viewer. and try to change the startMode of your application pool to AlwaysRunning:
Open Internet Information Services (IIS) Manager.
In the Connections pane, select the Application Pools node, revealing the Application Pools pane in the main view.
Click Advanced Settingsā€¦
Locate the Start Mode option under the General group and set it to AlwaysRunning.

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).

Visual Studio 2010 displays IIS 7 page on debug instead of my project

This is my first ASP.NET project so I am a bit of a rookie when it comes to a lot of the configuring of IIS/Visual Studio so bear with me...
I am using Visual Studio 2010 running on Windows Server 2008 SR2. We recently did some updates on the server and now my project no longer loads when I attempt to debug. When I try to debug the default "Welcome" page for IIS 7 loads instead of my project. I am set up to use the development server to debug, not IIS so I don't understand why I get the IIS page. Before the updates the debugger was pulling up my page without any issues.
Any ideas? Thanks in advance!
It looks like IIS is now bound to the port number that Visual Studio Development Web Server was using previously. You can change the port number in the properties of the web site project.
I have found a solution to my issue. I decided to use IIS instead of the Development Server for debugging. After attempting to debug unsuccessfully yet again, I took a look at the identity that was being used in the application pool and I changed to one with more privileges and that seemed to do the trick. Thanks for the suggestions.
I had the same problem but non-of the earlier answers worked.
I am using Windows 7 enterprise 64-bit, IE11, VS2010, Silverlight 5
I have been developing and maintaining a number of Silverlight projects for the past 5 years, and have always been able to debug them within VS2010 using the ASP.NET Development Server. However, on returning from some well deserved holiday, I found that none of my existing Silverlight projects would run in the debugger. In each case there is a Web project set as the start-up project, and in each case on starting the project within VS2010 (with or without debugging) I got the IIS7 web page instead of my application.
I tried creating a new Silverlight web application, and found that this started normally in the ASP.NET Development Server. I checked my source code and found that no changes had been made in my absence.
After a lot of head scratching, etc., the solution was to clear the IE cache. These are the explicit steps I used:
Close all instances of IE and ASP.NET Development Server.
Open Internet Properties from the Control Panel.
Click "Delete" on the General Tab.
In the Delete Browsing History box check the following options:
a) "Preserve Favourites website data"
b) "Temporary Internet files and website data"
c) "Cookies and website data"
Leave the others unchecked
5) Click "Delete" and wait for the command to complete.
6) Close the Internet Properties box.
7) Rebuild ASP.NET project
8) Start (with or without debugging) in VS2010 - it should now load normally.
Hope this works for you.

How to troubleshoot app domain shutdown due to "change in app_offline.htm", after editing file in Visual Studio?

Every time I change a file in a web project in Visual Studio (.js, .css, .cshtml, whatever) my app domain immediately shuts down and restarts. The shutdown message (which I log) is "HostingEnvironment initiated shutdown / Change in App_Offline.htm"
This just started happening after months of normal development. I'm looking for an explanation, or suggestions for troubleshooting.
Relevant info:
This occurs after changing a file in the web project. I am NOT doing a compile.
ASP.NET MVC 3 with the T4MVC plugin
Occurs when I change a view or any content file [.js, .css] referenced by web project
Project is configured to use Visual Studio internal web server, but I am accessing the website via IIS. [Web site directory points to the web project directory on disk]
I do not have an app_offline.htm file, nor do I see one created for me
Files in /bin/ do not appear to be changed [timestamps don't change]
I am using NCrunch, but this still occurs with it disabled
This only occurs when I change a file in Visual Studio. Editing with text editor does not cause the app domain restart.
How do I figure out what Visual Studio is doing to cause this? This makes it very difficult to work on html/css/javascript, for obvious reasons.
It appears that uninstalling and then re-installing T4MVC fixed the problem.
This might be relevant: a few days before I noticed this app domain restart issue, something happened and created a second T4MVC.cs file [called T4MVC1.cs]. This caused compilation errors from things being defined twice, and deleting the original T4MVC.cs file fixed that problem.
When I uninstalled and reinstalled the T4MVC package from nuget, I modified the web.csproj file and updated the <LastGenOutput> element to have a value of "T4MVC.cs".
I don't know if the issues with the generated file were related to the app domain restart issues, but after removing and reinstalling the T4MVC package and restarting Visual Studio the issue has gone away.

Why can't I edit my ASP.NET Web application at run time?

Why are the code-behind pages for an ASP.NET web application locked at run time? I have older projects (probably defined as "web sites" instead of "web apps") where I can edit the code behind, refresh the browser, and see my changes. With the web app, I have to continually close and reopen the browser if I want to see my changes live. Is there a setting or something I'm missing to allow me to edit at run time, and without restarting the debugging session?
You can enable Edit and Continue in the project properties. Right click the project in the solution explorer, select the Web tab and check Enable Edit and Continue.
Now you can edit your sources, but you have to pause the debugger to do so.
When using IIS as your development server, Edit and continue is not currently available for Visual Studio for ASP.NET.
See this blog entry, however, that shows it is possible for the Visual Studio 2005 Web Application Project Project type. It requires using the Visual Studio Development Server (Cassini) during development instead of your local IIS (see the properties box on the project).
No, in web applications, the codebehinds are pre-compiled into dlls, so any change in the dlls will recycle the App pool, and stop your debugging session,
If you press ctrl-F5 instead of just F5 to start (or host you site in IIS), you start without the debugger, and don't need to restart the browser all the time...
Unless you really really need to debug a problem you can't figure out, You should start the web app without debugger, makes it snappier to start up. Every minute spent debugging is a minute not spent writing a unit test. IMHO you should write unit tests, they last longer.

Resources