views:

86

answers:

5

The default ASP.NET web server that launches from within Visual Studio (Casini) is a little buggy on my development machine, so I like to publish to a local IIS instance on my dev machine and look at the web application there. However, I'm not automatically in "Debug Mode" when I launch the application this way.

I know that VS 2010 has an "Attach to Process" debug feature, but I'm not sure exactly how to use it. What do I need to do to be able to debug a local IIS ASP.NET web application from within Visual Studio? Specifically:

  • What settings do I need to change in the configuration of my web application?
  • What "Package/Publish Settings" do I need to change?
  • Is there anything I need to change in IIS?
  • Is there anything special I need to do in the "Attach to Process" screen?

Background Information: I'm running Visual Studio 2010 on Windows XP SP3 with IIS 5.1 and .NET 4.0.


Additional Information:

I should add that I've tried attaching to aspnet_wp.exe, but when I go to a page that I know has a breakpoint in it, I get the following message when I hover over the "open circle" breakpoint:

The breakpoint will not currently be hit. No symbols have been loaded for this document.

A: 

I also develop my web apps on a local IIS. For local IIS debugging, F5 has always worked for me.

If you must use attach to process, for whatever reason, ensure that you are either attaching to a local process or that the remote debugger is running on the remote machine. The application must be spun up in advance, say, by requesting a page in a browser. Use iisapp (IIS 5.1, 6.0) or appcmd list wp (IIS 7+) to determine which process ID belongs to which application pool (only necessary if you have 2+ application pools, really), and then get rolling with Attach to Process.

kbrimington
+5  A: 

Al you need to do is use attach to process and target aspnet_wp.exe. It could possibly be w3wp.exe depending on flavor of OS. I used to have a macro for doing this but it stopped working after VS2008.

Chris Marisic
Thanks for the answer. I tried to attach to aspnet_wp.exe, but it doesn't seem to be stopping at my breakpoints. I've updated my question with more information.
Ben McCormack
A: 

I have never made any special settings, and the attach to process gadget works very well. Just attach to the aspnet_wp.exe process and there you go.

Ray
+1  A: 

Right click on your web project in VS, go to start options and choose Use Custom Server, pasting in the localhost address you have for your site in IIS.

Hit F5, will run in IIS.

Paddy
A: 

I wasn't ever to get it work using F5 in Visual Studio, even when it was set up to deploy to the local IIS server. I'm not sure what exactly the problem was, but I eventually was able to get it to work in a much more "manual" fashion. A big part of getting this to work is to make sure you are generating debug symbols and deploying them to your web site. Here are the steps I took to eventually get it work:

  1. Create a new folder for your application on your local hard drive that will be used for your web application.
  2. Manually create a new Virtual Directory within IIS that points to the folder you created.
    • Make sure the web site properties or virtual directory properties in IIS are set to use ASP.NET 4.0 if you are using a .NET 4.0 web application.
  3. In VS 2010, right click on your web project and click "Publish." Use the following settings:
    • Publish method: Web Deploy
    • Service URL: http://localhost
    • Site/application: IIS Web Site Name/Virtual Directory
      • You need to specify the IIS Website name followed by the name of the Virtual Directory you just specified. The default name of the web site is usually just Default Web Site. For example, if you named your Virtual Directory MySolution.MyProject, you would specify Default Web Site/MySolution.MyProject as the Site/application.
    • Mark as IIS application on destination: I leave this unchecked.
    • Leave extra files on destination (do not delete): I currently leave this unchecked.
  4. In VS 2010, Right click on your web project and choose "Properties." Use the following settings:
    • In the Compile tab:
      • Click the "Advanced Compile Options..." button (I'm using VB.NET; it might be slightly different in C#).
      • Make sure "Generate debug info" is set to Full. (There's also an option for pdb-only, which I didn't try. This might work as well).
    • In the Web tab:
      • Under Servers, choose Use Custom Web Server and specify the address of your new application; for example: http://localhost/VirtualDirectory.
      • NOTE: Since I didn't end up debugging the application using F5, I'm not sure I needed to do this step.
    • In the Package/Publish Web tab:
      • You should be able to use the setting Only files needed to run this application for Items to deploy....
      • Make sure Exclude generated debug symbols is unchecked.
        • NOTE: For security purposes, you probably wouldn't want to deploy debug information in a production environment unless absolutely necessary.

After you've done the above, you should be ready to deploy your application so that it can be debugged. Here are the steps I use to deploy and subsequently debug the application:

  1. Right click on your web project and click Publish.
    • Make sure your settings are still defined from step 3 from above.
    • Click the Publish button. This will automatically build the application according to the current Build Configuration and publish it the the specified web host.
  2. Go ahead and navigate to one of the pages in your web application to make sure the application starts up.
  3. In VS 2010, click on the Debug menu and choose Attach to Process. Select the ASP.NET process that's running (In Windows XP, it's *aspnet_wp.exe*) and click Attach.
  4. You should now be able to add breakpoints to your code that will fire when you navigate to various pages in your web application from the browser.

While this method works great, keep in mind that it's not just attached to your local development environment. If another user on a different computer were to access the web application, I believe the breakpoints will still fire as long as your are debugging the process.

Ben McCormack