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.
Related
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.
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.
This seems like a typical Microsoft bug. I have a project that when I click launch despite the fact that it's set as the default project is launches a skeleton MVC app as opposed to the MVC app that I'm currently working on.
To fix the problem I have to close down Visual Studio completely and relaunch my solution. I press f5 or just run the app and it works.
What I find interesting is this mysterious skeleton app which seems to be ASP.NET temporary files is the same port as my project. This happens multiple times a day while developing this particular app on the particular port. Does anybody know why Visual Studio 2013 is doing this?
Okay so this is a Microsoft bug. It turns out the project I'm working on does have identical names to another project that I was working on except in a different codeline. Visual Studio gets all confused and launches the old app in cache instead of the app I'm working on. The only way to fix this it appears it to manually change the port number for IIS Express.
For more information check this out.
https://connect.microsoft.com/VisualStudio/feedback/details/786645/vs-launches-the-wrong-mvc-website-when-two-identically-named-solutions-are-open-at-the-same-time
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: