Started working this morning and quickly discovered Visual Studio 2017 debugging of my local IIS site has quit working on debug F5 startup. After a few hours of tracking things down I figured out that it is attaching to the wrong site, w3wp.exe process. I can manually attach and all is well.
If I stop the site that VS has this affinity to I get the standard ... Unable to start debugging on the web server. Unable to connect to the remote server'
Anybody know how Visual Studio chooses the w3wp.exe process that the debugger wants to attach to on debug starts?
Finally resolved after half a day of time spent and don't have an exact resolution. This project is a Web Site running on a particular port at same level as the Default Web Site. The fix was adding in the port to the project properties page 'Project Url' and removing it from showing up underneath the Default Web Site. I never thought the port was included in the project Url where the Virtual directory is created since original setup a few weeks back. If my memory is wrong then something removed the port from this Project Url setting.
I also noted that for some reason this site showed up in IIS Manager in 2 locations, under the Default Site as well as the site itself. When originally setup the Default Site was deleted and added back later but all had been working fine since then.
After more thought I also recall that the I discovered when the site did not first run in debugger it had been changed to run under IIS Express. I don't know why that happened unless I did seem sleep coding over the weekend.
Related
I cannot get Visual Studio 2015 to attach remotely to my Azure site. Or, rather, it attaches okay, but no breakpoints are ever hit.
I've confirmed I'm publishing a debug build. I tweaked web.config to require that.
I've confirmed remote debugging support for 2015 is activated within the Azure portal.
The site launches fine after the attachment...just no breakpoints.
This is an MVC6 site using rc1.
For the sake of other people struggling with this, it turns out VS2015, even with all the latest updates, isn't "aware" of dnx running under Azure. So it attaches to the wrong process on the Azure site.
After doing "Attach Debugger" within Cloud Explorer or Server Explorer, you must go into Debug -> Attach to Process, and do two things:
change the qualifier so it points at the remote Azure site
manually attach to the dnx.exe process
The first step seems to get "remembered" by VS 2015. The second step most definitely does not; you have to do it every time you do a remote debug attachment.
Also, you need to refresh the site in your browser after doing all of this for the debug cycle to start.
Here's a link that explains this a bit more: https://blogs.msdn.microsoft.com/webdev/2016/03/21/remote-debug-aspnet-core-on-azure/
Try downloading cloud explorer here
attach debugger as below
Enable debugging setting in azure portal with visual studio version as below
Attach remote debugger to w3wp as below
5 Make sure Debug must be = true
Make sure you deploy application to azure in debug mode
I created a new ASP.NET 5 RC1 WebApp using Visual Studio 2015 and published it to Azure. I turned on remote debugging and selected VS 2015 for the debugger. I can attach to the WebApp, but any breakpoint I set is not showing up completely red. Hovering over the breakpoint gives you the message "The breakpoint will not be currently hit. No symbols have been loaded for this document." I did a bunch of searches to see if anyone else had encountered this issue. I found some articles that seemed to indicate the solution:
Remote debugging Azure website: Breakpoints not hit
Azure Website Remote Debugging with git deploy not working
I tried turning off "Just my code" and adding the app setting, but neither of these worked. I even had a colleague try the same thing from his system and his Azure account to make sure it wasn't just an environmental issue on my system. Does anyone know how to fix this?
The problem is the VS 2015 Azure tooling is not yet DNX aware at the debugger level. So for now, you'll need to manually attach the debugger, using the steps documented in this article.
Once you get the list of processes, you'll want to attach to the dnx.exe process, instead of the usual w3wp.
I just tried with a new ASP.NET RC1 app, and was able to set and hit breakpoints. It took a while to attach and load symbols, so be patient :)
I'm trying to setup debugging on a class ASP project in VS 2010, and in doing that am trying to attach it's debugger to w3p.exe. I'm using Windows 7 64-bit and IIS 7.5. I've used this method successfully a few times before on another machine.
However, I'm finding that this time I am unable to attach the debugger. It's saying:
Unable to attach to the process. A debugger is already attached.
But I can't figure out what it might be. How can I determine this? Or could it be something else? I've rebooted my PC and can't yet see signs of anything running which looks like a debugger.
Setup
In case it helps, here's the steps I used to setup the environment, which I documented from my previous successful attempts:
Created new empty Visual Basic .NET Web (Best to create in C:\inetpub\wwwroot\, otherwise you will have security/ACL issues when loading the site).
Copied the contents of site folder to project folder.
In solution explorer, selected to show all files not in project. Selected all files and right click and select: "include in project".
Under project properties -> Web -> Set to use IIS and start with URL http://mysite.local
In hosts file pointed mysite.local to 127.0.0.1
In IIS setup new website pointing to the files with a host header of mysite.local
Go to application pools, ensured mysite.local was set to classic mode. No managed code.
Under ASP -> Enable Parent paths and make sure server-side debugging is enabled
Under error pages, make sure full details are shown.
Debugging in Visual Studio 2010
Run VS 2010 as Administrator
In your project, use Ctrl+F5 to run without debugging
Now, in the menu go to Debug -> Attach to Process -- This is where I fail
Tick show processes from all users AND show processes in all sessions
Make sure it is set to automatically determine type of code to debug
Look through the w3p.exe processes in the list, and based on the IIS POOL\site name, pick the right process.
Set your breakpoints and refresh -- debug as normal.
Are you having some Debug Diagnostics Tool running on your machine. Sometimes back i had the same problem the Debug Diagnostics Tool was debugging my w3p process.
Many a time have I come across the issue of not being able to run debugging from within Visual Studio by hitting F5, and having to resort to attaching to a process.
For starters, lets assume the following
Visual Studio is running in an administrative context,
IIS7 is installed with IIS6 management options and Windows authentication enabled at a root level
You are an administrator on your local machine.
You are attempting to debug your web application which is running on said local IIS instance. The Web application project settings (Properties>Web) has been setup with the URL of the site
Hitting 'F5' results in an error from Visual Studio saying;
"Unable to start debugging on the web server. The IIS worker process for the launched URL is not currently running."
I've come up a blank after a couple hours trawling the web for answers, so I thought I would give StackOverflow a go.
If I get many good suggestions here then I thought it would be a good idea to start a checklist (which would hopefully turn into a wiki) of things one should try in order to get F5 debugging working.
"Unable to start debugging on the web server. The IIS worker process for the launched URL is not currently running."
This error message means that there is currently no ASP.NET worker process running on the host you are trying to connect to so the debugger cannot be attached.
Before hitting F5 make sure that
You connect to the right host (a problem might be 127.0.0.1 vs. host name)
There is a w3wp.exe process shown in Task Manager.
If the worker process is not running you can start it manually by opening one of the ASP.NET pages of your application.
Somehow, since some time I'm experiencing problems with debugging my ASP.NET website.
Every time I try to debug the website ASP.NET shuts down (global.asax_Application_End is called).
I believe this is triggered because the site is built by Visual Studio. However, manually (re)build the site and then start debugging also restarts the site. Even debugging and ending the debugging session, clicking a couple of buttons on the site to get to the desired state, and start a debugging session again still triggers a build action, which causes the site to restart.
Since restarting resets HttpRuntime.Cache booting the site takes a long time, and sometimes I want to debug some situation that involves caching.
Now there is a setting on the website's property pages:
Start Action (F5):
Before running startup page:
No Build / Build Page / Build Web Site.
I've set it to No Build, restarted Visual Studio, but still it triggers the build action every time I hit F5 or the Start debugging button...
Anyone any ideas as to how to resolve this??
Thanks,
Jaap
We've solved this by converting our project to a Web Application instead of a Web Site. This had some impact on our architecture since we had some classes in app_code which we needed to use reflection on during site startup.
It turns out that the Web application in combination with "Use Custom Web Server" fixed out issue!