we currently have 2 developers working on 2 different websites, on the same server.
when an error occurs in one of the web applications, that debug option pops up for the wrong developer. how do we specify what VS instance is to be used for which w3wp debugger process attached?
Here are a couple of options sorted from best to worst...
Run Visual Studio locally on the developer's computers so this isn't a problem.
On the server, use Visual Studio's web server instead of IIS. This gives each user an automatically created local process that can be debugged.
If you must use IIS, configure each application in IIS so that they run in their own application pools. Each application pool gets its own w3wp process so your Visual Studio instances can attach to their own process.
Related
When I try to open two projects in two different instances of Visual Studio and run both of them locally in debug mode at the same time (say, a web application and the backend WebService that it uses) I get the error "Unable to start debugging on the web server. A debugger is already attached"
No one else in the office is able to do it either, except for one person, who can't figure out why it only works for him. The virtual directories in my computer's IIS seem to be set up the same way as his (I don't know about the settings).
I was also able to debug from two instances of VS at once at my previous job, so something about the setup here must be different.
I figured it out. Each project needs to be set to a different Application Pool. Found the answer here.
Since the same AppPool was being used by both the Web Application and Web Service, the same process hosted both. That is why as I had already attached the process in one instance of Visual Studio, I could not attach it in the second instance of Visual Studio.
Changing the AppPool had the effect of both being hosted in different host processes and hence they could now be debugged using different instances of Visual Studio.
Why the heck does visual studio (2012 I'm using, I think previous versions did this too) load the WebDevServer for all web projects in my solution when I tell my solution to attach to another process?
If I'm attaching, obviously I don't want it to load processes because I'm debugging an already running process! Gah!
Anyone know how to make it not do this when I'm attaching to another process? This is driving me nuts because the web dev servers load up and try to acquire resources in use by the already running processes I'm trying to attach to..
I have found this occurs on some projects. If you change the project properties > Web > Servers. And the choose "Use Custom Web Server" that will ensure that Visual Studio does nothing when you attach.
In Visual Studio 2010,
I want to debug two web applications running on IIS at the same time.
When debugging the first application it is ok. But when starting to debug the second application and first program is still in debug mode, Visual Studio prompts:
unable to start debugging on the web server. a debugger is already
attached
How can I solve this problem?
To summarize, one has to set different application pools in IIS for the two applications to debug.
Here is a rough instruction, given that both applications have been deployed to IIS once within Visual Studio.
Open the Internet Information Services (IIS) Manager
Click Application Pools on the left pane
On the right pane add another integrated application pool, let's name it Second ASP.NET 4.0 Integrated
For one application, open the Advanced Settings...
In the properties view finally select Second ASP.NET 4.0 Integrated as the application pool
This way the applications should be debuggable in parallel because each Application Pool spawns a new operating system process to which a separate debugger can be attached.
A windows process can only have one debugger attached to it at a given time. If you get that message it means that you're attempting to debug the same process twice which won't work. But that also means you should be able to debug both web applications in the instance of Visual Studio that's already attached. It may require a few extra steps though to get it to acknowledge the other code
Disable "Just My Code" (Tools -> Options -> Debugger, uncheck "Enable Just My Code"
You may need to manually load symbols for the other web application through the modules window (Debugger -> Windows -> Modules)
After that though (second step may not be necessary) you should be able to set break points in both web applications and otherwise debug them.
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.
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