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
Related
Since Azure is being updated rather often, I have yet to find an updated guide on how to do remote Azure debugging specifically for Visual Studio 2017.
I would simply like to know how to attach to the process running on the Azure server so that I can debug my web app.
If you are talking about debugging a web site or api hosted in app service or service fabric, you should try using Cloud Explorer. My experiences with it have been very good.
Its pretty simple. When you open up Cloud Explorer, it shows all subscriptions and resources available to your account(s). When opening e.g. the app services for your subscription, you deployed application will be visible. You can then simply right click and say "attach debugger", as can be seen here:
You can add multiple accounts to visual studio, and select the one that has access to the resource.
This is a more extensive tutorial on how to use the Cloud Explorer:
https://learn.microsoft.com/en-us/azure/vs-azure-tools-resources-managing-with-cloud-explorer
There were different ways of doing this, but I think a few of them are outdated.
Anyways, this is what worked for me:
Turn on Remote Debugging under Azure Portal -> Your web app -> Application Settings
Attach to the process in Visual Studio 2017 -> Debug -> Attach to Process.. -> Input YourWebAppName.azurewebsites.net:4020 and hit
ENTER
It'll ask for credentials. My AD credentials did not work here, which brings us to step 4..
Azure Portal -> Overview -> Get publish profile. It'll download the publish profile for your web site. In that file, you'll find
msdeploySite, userName and userPWD. Use them for step 2.
You should now be able to see the w3wp process and attach your debugger to it.
These answers/sites helped me find the solution:
https://blogs.msdn.microsoft.com/benjaminperkins/2017/01/09/cannot-publish-to-soveriegn-cloud/
https://blogs.msdn.microsoft.com/benjaminperkins/2017/06/06/remote-debug-your-azure-app-service-2017-including-asp-net-core/
https://stackoverflow.com/a/35738995/2504659
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.
I have read this question and this page linked to in the question, as well as dozens of other articles about debugging asp classic with VS but it's still not clicking for me.
I am using VS 2010. The files I want to debug live on a remote server. I have installed the Remote Debugger on the server. I opened the website and attached to the w3wp.exe process on the remote machine. I created some breakpoints but I am still getting "The breakpoint will not currently be hit. No symbols have been loaded for this document" on those breakpoints. Is that the problem or is that a symptom of a larger problem with what I am doing?
First, by default, when you open a web site in Visual Studio, you're opening it via the file system, not via IIS. If this is the case, then Visual Studio uses the internal Cassini web server, rather than IIS.
The Cassini web server does NOT run classic ASP. IIS does. So the first thing you need to do is figure out how to debug in IIS.
It should go without saying, you need to have IIS installed on the machine you're working with, and have the web site you're debugging set up the same as it would be on the server. (so you should be able to run http://localhost/somepath and be able to see your site)
You also need to attach to the running process of Internet Explorer. There's a link to that as well.
Next, you need to get Visual Studio to attach to IIS and execute the web site rather than use the built-in web server and enable debugging.
That's covered here: This topic is no longer available (which is the first child link of the page you liked to in your question here.
From there, you should be able to follow the remaining links and get up and running.
Edit - added
This article takes you through it step-by-step.
Debugging Classic ASP ( VBScript ) in Visual Studio 2008
I've just had this problem when trying to debug a classic ASP application in VS2012.
There's no need to copy PDB files, because there aren't in this kind of projects, so follow this steps:
Be sure that ASP compatibility is turned ON in your IIS installation (Control Panel -> Enable/Disable Windows features -> Internet Information Server). You can install all features if you want to be sure.
Access to the IIS administration.
Locate your WebSite, then access the ASP configuration.
Find "Debugging properties" and then enable client and server debugging. You can also enable error sending to the browser.
After that, just attach the VS2012 debugger to the "w3wp.exe" process. DEBUG -> Attach to process....
This will work for local debugging. If you want to do remote debugging, you must prepare the remote server to allow remote debugging (TIP: Use the same user in both, server and your machine, and be sure it has enough privileges). For more information take a look at:
Installing the Remote Tools
Debugging Classic ASP ( VBScript ) in Visual Studio 2008
I'm using Visual Studio 2008 to develop ASP.NET applications. Currently I'm debugging with running on IIS. I would like to switch to the development web server (Cassini) for debugging, so that I can use features like edit and continue. The reason that I'm not, is because the development web server only starts up when you are in debug mode. Is there any way to keep it running all the time, and just have Visual Studio attach to the existing server process like it does with IIS?
Rihan is partially correct...
In your Project Property page, Web tab: Enable Edit and Continue
If checked - The Development server will close when the app (not VS) stops.
If unchecked - Development server keeps running
You can also start your cassini server from the command line which takes alot of pain out of the whole "debug" effort...
Check out a good snippet here on how to do this: https://thoughtjelly.wordpress.com/2009/05/13/launch-cassini-from-the-command-line/
Once started, the built-in web server continues executing even when you stop debugging, as long as your VS2008 project is still open. Just start up the debugger when you want to start debugging again. I typically have another browser window open and interact with the built-in web server from there instead of the browser window that it opens so I can keep working with the application in the same state even after turning off the debugger (which closes the opened browser window).
I'm running VS2008 on Windows XP SP3.
The simplest way I have found to acheive that is by launching the debugger as normal. Then in Visual Studio goto the Debug menu, and select detach all. It detaches from the Cassini web engine, but it does not shut it down, as it does when stopping debugging.
I am quite sure you are know that there is command line swithces that you can you use to launch the cassini engine, but my guess is you are looking for something slightly easier.
Detaching does not close the browser window that visual studio launched, and if you do close that spesific web window then it will stop debugging.
I am running VS 2008 SP1 on Vista 64x SP1 without IIS.
Hope it helps
Rihan Meij
I have 3 web sites, with Single sign on between each site so I need to start all 3 with attach to process. However, there was no process to attach the debugger to, and whenever I started a project with F5 then stop it, the visual studio web server closed.
The Enable Edit and Continue option didn't change anything.
So to start the web server and keep it running so that you can attach the web project to the process, I simply did a "view in Browser" (ctrl+shift+W). This started the server process but not the project nor the debugger. I could then attach to process easily.
In Visual Studio 2015 you do this by going to Tools > Options > Debugging > General and unchecking the "Enable Edit and Continue" option: